perl files via webserver als root laten uitvoeren

[Verwijderd]

Ik wil een perl file als root laten uitvoeren via de webserver, is hier een mogelijkheid voor zonder de webserver als root te laten draaien?

ik wil nl een commando, die alleen als root kan, via dat perl bestandje aanroepen maar via apache....

tips graag

[wouzer]

Hmm, niet echt iets dat je zou willen, tenzij je het heeeel goed afschermd. Ik heb zoiets wel eens gedaan door het commando wat je door je script wil laten uitvoeren naar een aparte (voor de bezoeker van de site afgeschermde) directory te copieeren en deze suid te maken. Dus chmod 4755 <proggy>

[Infern0]

Ik heb zoiets opgelost door een cron job te gebruiken, dan wel niet met perl maar met php.

De cronjob loopt bv elke 5 min en kijkt ergens naar (in mijn geval een parameter in de DB) en voort dan de opdracht als root uit (als die parameter op 1 staat).

[Verwijderd]

je kunt een wrappertje schrijven ...
bijvoorbeeld in C ofzo die het commendo (dat je als argument meegeeft) uitvoerd nadat ie ff een setuid naar root heeft uitgevoerd.

maar zelfs dan werkt het nog niet met ALLE commando's ! (is mijn ervaring ... bijv passwd mocht ik niet uitvoeren)

gebruik de search ffies op wrapper

[Verwijderd]

Op vrijdag 25 januari 2002 12:16 schreef rlensen het volgende:
Ik heb zoiets opgelost door een cron job te gebruiken, dan wel niet met perl maar met php.

De cronjob loopt bv elke 5 min en kijkt ergens naar (in mijn geval een parameter in de DB) en voort dan de opdracht als root uit (als die parameter op 1 staat).

hmm hier had ik dus ook al aan gedacht, alleen leek me dit niet echt een handige oplossing, andere oplossingen zijn ook niet echt praktisch; ik wil oa maken dat een gebruiker via een webinterface zijn wachtwoord kan veranderen enzo.... opzich kan ik het perl script wel veilig krijgen zodat alleen een user zijn wachtwoord kan doen, maja.... hmmmmmmmmmm

[Verwijderd]

code:

#include <stdio.h>
#include <unistd.h>
#include <strings.h>

#define PASSWORD "raadjelekkertochniet"

int main(int argc, char *argv[])
{
    char password[sizeof(PASSWORD)+1];

    if (argc < 2) return 2;

    setvbuf(stdin, NULL, _IONBF, 0);

    fgets(password, sizeof(PASSWORD)+1, stdin);
    password[sizeof(PASSWORD)-1] = '\0';

      if (strcmp(PASSWORD, password)) {
      fprintf(stderr, "Access denied\n");
      return 1;
    } else {
      setuid(0);
      setgid(0);
      return execv(argv[1], argv+1);
    }

    return 0; /* never reached */
}

dit is een oude die ik ooit eens heb gekregen ..
met

PHP:

<?
 $fp = popen($wrapperfile, $file_die_je wilt_exec)
fpus($fp, "wachtwoord_uit_c_file\n");
?>

zoiets

[Verwijderd]

Op vrijdag 25 januari 2002 09:46 schreef wouzer het volgende:
Hmm, niet echt iets dat je zou willen, tenzij je het heeeel goed afschermd.

Inderdaad, heeeeeeel goed.

Ik heb zoiets wel eens gedaan door het commando wat je door je script wil laten uitvoeren naar een aparte (voor de bezoeker van de site afgeschermde) directory te copieeren en deze suid te maken. Dus chmod 4755 <proggy>

Volgens mij is het al voldoende/beter om het perlscript zelf te suid te maken. Dan draait het gewoon als die user (root in dit geval).

[igmar]

Volgens mij is het al voldoende/beter om het perlscript zelf te suid te maken. Dan draait het gewoon als die user (root in dit geval).

Alle +s bits op alle scriptfiles worden genegeerd. Een Perl file +s maken heeft geen zin, tenzij je suidperl hebt geinstalleerd. Dat is dan weer een wrapper. Vreselijk lelijk IMHO.

[Verwijderd]

hmmmmmmmm

ik ben niet zo heel erg bekend met linux en wrapper, suid en dat c proggie zeggen mij weinig, maar is het nou wel mogelijk dan om dat scriptje als de user root de draaien of niet met suid

[Verwijderd]

wonder boven wonder werkt het

alleen nog niet helemaal; ik heb een script en die draait als root via de webserver, alleen bepaalde dingen (vrijwel alle dingen) werken niet en geven de volgende error:

Insecure $ENV{PATH} while running setuid at ...

is deze error op een of andere manier te voorkomen ?

[Verwijderd]

Als een script suid draait (wat dus wel gewoon kan), dan gaat perl automatisch in Taint-mode. Dat is hetzelfde wanneer je niet alleen -w zou gebruiken (dat doe je toch wel?) maar ook -T. Dan wordt alle data die van buitenaf komt (denk aan form-values) als Tainted aangemerkt.

Dat vindt perl niet fijn, en dus moet je er nog iets mee doen. (Untainten). Lees hierover meer in de perlsec: Laundering and Detecting tainted data.

Ook de PATH environment variable moet je aanpassen, zodat het script niet te veel enge dingen kan doen. hint: perlsec: Cleaning up your Path

Kijk volgende keer zelf ook gewoon even in de perl FAQ en docs.

[Verwijderd]

Op zondag 27 januari 2002 17:09 schreef nonomen het volgende:
Als een script suid draait (wat dus wel gewoon kan), dan gaat perl automatisch in Taint-mode. Dat is hetzelfde wanneer je niet alleen -w zou gebruiken (dat doe je toch wel?) maar ook -T. Dan wordt alle data die van buitenaf komt (denk aan form-values) als Tainted aangemerkt.

Dat vindt perl niet fijn, en dus moet je er nog iets mee doen. (Untainten). Lees hierover meer in de perlsec: Laundering and Detecting tainted data.

Ook de PATH environment variable moet je aanpassen, zodat het script niet te veel enge dingen kan doen. hint: perlsec: Cleaning up your Path

Kijk volgende keer zelf ook gewoon even in de perl FAQ en docs.

thx!

die PATH environment variabele was het probleem werkt nu als een zonnetje

[jep]

Suexec? Dat is hier voor lijkt me he Ik gebruik 't op mn werk voor alle virtualhosts. Allemaal perl onder hun eigen username. Dit kun je dus ook met root doen lijkt me.

Suc6

[Verwijderd]

Op zondag 27 januari 2002 20:50 schreef j3p het volgende:
Suexec? Dat is hier voor lijkt me he Ik gebruik 't op mn werk voor alle virtualhosts. Allemaal perl onder hun eigen username. Dit kun je dus ook met root doen lijkt me.

Suc6

nee dat zou niet lukken met de opzet die ik deed, maar suidperl incombinatie met bovenstaande dingen heb ik het aan het werk gekregen

[jep]

Choeso kertje!

[zerok]

Op vrijdag 25 januari 2002 12:40 schreef Maentor het volgende:

code:

code

Misschien zeur ik nu maar echt veilig is dit niet. de passwd string die je toch niet raad is wel te zien met bijvoorbeeld 'strings exec-naam' kan knap vervelend zijn als er een crackertje op je systeem zit.

zeroK