Script uitvoeren met root rechten door niet root user (fbsd)

[Verwijderd]

Het gaat om FreeBSD (al zal het in linux misschien hetzelfde gaan):
Is het mogelijk om een script te laten uitvoeren met root permissies op aanvraag van een gewone gebruiker? Zonder natuurlijk die gebruiker het root password te moeten geven.
Ik wil namelijk dat de www user een bepaald scipt kan uitvoeren dat dingen doet dat alleen root mag doen. Uiteraard is het scipt zodanig geprogrammeerd dat het alleen doet wat het moet doen.
Een daemon programmeren die een keer door root geactiveerd wordt en dan requests van users kan uitvoeren is te moeilijk.

[_Squatt_]

suid zetten zal niet werken, waarschijnlijk is 't met 'sudo' het makkelijkst op te lossen. Even de search doorpluizen, er zijn al wat topics over geweest .

[Wilke]

Daarvoor heb je het 'sticky' bit - zie 'man chmod'.

Als je de file eigendom maakt van root, zorgt dat gewone users hem kunnen uitvoeren, en dan het sticky bit zet.

Dus zoiets:

code:

chown root.root naam-van-script
chmod 2755 naam-van-script

Als het goed is kun je nu als gewone user dit script aanroepen, maar zal het dan draaien als root. Dit is trouwens wel een major security risk, vooral als je zo'n script vanuit een web-interface gaat aanroepen. Controleer ontzettend goed of de parameters wel goed aan het script worden meegegeven (dus dat users niet een andere file kunnen openen/wijzigen dan jij wil), en gebruik dit sowieso alleen bij delen van een site die goed beveiligd zijn (ssl, wachtwoord, .htaccess)

Squatt: waarom zou dat niet werken dan

[ Voor 3% gewijzigd door Wilke op 05-02-2003 20:01 ]

[Kees]

Wilke schreef op 05 February 2003 @ 20:01:

Squatt: waarom zou dat niet werken dan

Omdat bash daar niet intrapt

[Kees]

kees@kees kees $ cat suidtest
#!/bin/bash
id

kees@kees kees $ ./suidtest
uid=1000(kees) gid=100(users) groups=100(users),10(wheel),18(audio)

kees@kees kees $ su
Password:

kees kees # ./suidtest
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

kees kees # l suidtest
-rwsr-sr-t 1 root root 14 Feb 5 20:17 suidtest

[ Voor 14% gewijzigd door Kees op 05-02-2003 20:20 ]

[Verwijderd]

Wilke bedankt.
Hoe kan je zorgen dat het script alleen door het juiste scipt kan worden geactiveerd? Want al zeg je dat de webserver dat die het scipt niet mag uitvoeren kan kan het niet worden uitgevoerd door een bezoeker van de website maar een andere user die de locatie en sourcecode van het scipt weet zou het alsnog kunnen aanroepen via een eigen scipt. Enige optie die dingen geheim houden? HTTP_REFERER Werkt niet neem ik aan (ik gebruik de exec functie van php om een php scipt los uit te voeren.

[deadinspace]

Wilke schreef op 05 February 2003 @ 20:01:
Daarvoor heb je het 'sticky' bit - zie 'man chmod'.

Op files heet die het setuid bit

Squatt: waarom zou dat niet werken dan

Omdat setuid bits op scripts niet werken - zie onder.

Kees schreef op 05 February 2003 @ 20:15:
Omdat bash daar niet intrapt

Dat heeft weinig met bash te maken; het is de kernel die suid bits moet honoreren, en het is de kernel die dit voor scripts niet doet.
De reden hiervoor is dat scripts met suid bits van oudsher (vroeger kon het wel nml) wandelende security holes waren. Dat komt omdat de gebruikte interpreter (vooral shells) vaak met environment variabelen, argumenten of andere truukjes beinvloed konden worden (denk aan step mode, debug mode, dat soort dingen), waardoor je die shell (die dus als root draait) meer kon laten doen dan de bedoeling was. De effecten hangen natuurlijk wat van het script en de shell in kwestie af, maar een root shell krijgen was nogal eens mogelijk.

Bij mijn weten negeert elke moderne Unix setuid en setgid bits op scripts.

Oh, en sudo is doorgaans een goede oplossing (was al genoemd), en misschien is suidperl handig (daarmee kun je setuid perl scripts maken).

Verwijderd schreef op 05 februari 2003 @ 21:25:
Hoe kan je zorgen dat het script alleen door het juiste scipt kan worden geactiveerd? Want al zeg je dat de webserver dat die het scipt niet mag uitvoeren kan kan het niet worden uitgevoerd door een bezoeker van de website maar een andere user die de locatie en sourcecode van het scipt weet zou het alsnog kunnen aanroepen via een eigen scipt. Enige optie die dingen geheim houden? HTTP_REFERER Werkt niet neem ik aan (ik gebruik de exec functie van php om een php scipt los uit te voeren.

In ieder geval het script alleen uitvoerbaar/leesbaar maken voor de webserver. In het geval van sudo kun je sowieso opgeven dat alleen een bepaalde user het script als root mag uitvoeren.

Maar ik neem aan dat je bang bent voor misbruik vanuit apache/php? Misschien kun je naar suexec (oid?) voor apache kijken, daarmee kun je specificeren dat bepaalde php files als bepaalde users mogen worden uitgevoerd... Zo zou je de php file die het script aanroept zèlf dingen als root kunnen laten doen.
Ik heb alleen geen ervaring met apache/suexec, dus hoe het precies werkt, wat de mogelijkheden zijn en hoe veilig het exact is weet ik niet.

[Verwijderd]

script omzetten naar native, en dan setuid bit geven.

Maar das makkelijker gezegd dan gedaan tenzij het een scriba script is oid

[Verwijderd]

Shit dat het setuid bit niet op scripts werkt

suexec Is geen optie want daarbij kan je niet iets als root laten uitvoeren.

Sudo blijft als enige over. Stel dat ik dan instel dat de www user dat scripje als root mag uitvoeren, hoe voorkom ik dan dat gebruikers die php scipjes in hun homepage gebruiken dat sciptje kunnen uitvoeren? PHP kan namelijk niet in safe mode en ik wil liever ook niet overal de exec(); functie gaan disabelen. Bij een normaal PHP scipt kan je met HTTP_REFERER kijken of het wel door het juiste scipt wordt aangeroepen maar in dit geval werkt die variabele natuurlijk niet.

[ Voor 16% gewijzigd door Verwijderd op 06-02-2003 22:20 ]

[deadinspace]

Weet je zeker dat je met suexec geen dingen als root kunt laten uitvoeren?

Ik weet niet of het mogelijk is, maar je zou anders misschien php files in users' homedirs als die betreffende users kunnen laten uitvoeren. Dan draaien die php files niet meer als je apache user en kunnen dus niet meer bij dat script.

Of andersom: met suexec die ene php file als een extra user uit laten voeren, en alleen die extra user rechten geven dat script uit te voeren.

[igmar]

Verwijderd schreef op 05 February 2003 @ 19:24:
Het gaat om FreeBSD (al zal het in linux misschien hetzelfde gaan):
Is het mogelijk om een script te laten uitvoeren met root permissies op aanvraag van een gewone gebruiker? Zonder natuurlijk die gebruiker het root password te moeten geven.
Ik wil namelijk dat de www user een bepaald scipt kan uitvoeren dat dingen doet dat alleen root mag doen. Uiteraard is het scipt zodanig geprogrammeerd dat het alleen doet wat het moet doen.
Een daemon programmeren die een keer door root geactiveerd wordt en dan requests van users kan uitvoeren is te moeilijk.

code:

#include <unistd.h>

int main(int argc, char **argv)
{
   execl("/pad/naar/de/exe", "exe", "arg1", "arg2");

   return 0;
}

compilen, chmod u+s en klaar is Kees

[u_nix_we_all]

Squad zei het al: sudo
Dat kun je per user configgen.
Of is dat er niet voor xxxBSD ?

[deadinspace]

igmar, u_nix_we_all: Dat is het probleem niet meer.

[Verwijderd]

Inderdaad. Al is het natuurlijk wel een handig ideetje om een programmaatje te maken dat het scipt uitvoert en de parameter doorgeeft. Zo kan je wel de sticky bit gebruiken en kan het zonder sudo.

Maar het probleem is nu dat ieder PHP scipt, dus ook dat van andere users, als www wordt uitgevoerd. Maar het is niet de bedoeling dat zij het scipt met root permissies kunnen uitvoeren.

[deadinspace]

Verwijderd schreef op 07 februari 2003 @ 23:02:
Inderdaad. Al is het natuurlijk wel een handig ideetje om een programmaatje te maken dat het scipt uitvoert en de parameter doorgeeft. Zo kan je wel de sticky bit gebruiken en kan het zonder sudo.

Mja, maar met sudo kun je vrij veel beperkingen opleggen, bovendien is sudo imho makkelijker, zeker als het om meerdere programma's gaat.

En zelf zulk soort dingen gaan maken brengt ook security risico's met zich mee als je niet goed oplet. Het gegeven programmaatje is eenvoudig, daarin kan weinig fout gaan, maar zodra je meer wil moet je oppassen.

Maar het probleem is nu dat ieder PHP scipt, dus ook dat van andere users, als www wordt uitgevoerd. Maar het is niet de bedoeling dat zij het scipt met root permissies kunnen uitvoeren.

Heb je al gekeken naar mijn voorstel? Dmv suexec het bewuste php script als user blaat laten draaien, en dan alleen de user blaat (die alleen bestaat voor dit doeleinde) toestaan het shell script als root uit te voeren?

[Verwijderd]

PHP via suexec draaien is lastig want dat kan alleen met de standalone versie van PHP maar 't is voor een programmaatje wel te doen.
Het zou wel fijn zijn als apache2+PHP niet meer experimental zou zijn. Apache 2 kan uid en gid per virtual host toewijzen.

[igmar]

Verwijderd schreef op 08 February 2003 @ 13:10:
PHP via suexec draaien is lastig want dat kan alleen met de standalone versie van PHP maar 't is voor een programmaatje wel te doen.
Het zou wel fijn zijn als apache2+PHP niet meer experimental zou zijn. Apache 2 kan uid en gid per virtual host toewijzen.

Apache 1 kan dat ook : www.jdimedia.nl/igmar/mod_suid/

[Verwijderd]

"And a final remark : It runs ONLY on Linux !!!"

Shit shit shit. Dit is precies wat ik zocht maar ik gebruik FreeBSD.
Of is die waarschuwing voor windows users en werkt het wel op een BSD systeem?

"This module gives the administrator the choice of running scripts inside and outside vhosts under their own UID and GID."

Geldt het niet voor de toegangsrechten van apache voor de betreffende vhost?

[ Voor 56% gewijzigd door Verwijderd op 08-02-2003 22:13 ]

[deadinspace]

Ik heb even vluchtig door de source van dat ding gekeken, maar ik zie zo snel niks Linux-specifieks (behalve dan een compile-check).
Volgensmij heeft de schrijver van die module alleen rekening gehouden met Windows en GNU/Linux: "het draait niet op Windows dus alleen op GNU/Linux".

Maareh, wat me meer stoort zijn de waarschuwingen mbt security...

[igmar]

Verwijderd schreef op 08 February 2003 @ 22:06:
"And a final remark : It runs ONLY on Linux !!!"

Shit shit shit. Dit is precies wat ik zocht maar ik gebruik FreeBSD.
Of is die waarschuwing voor windows users en werkt het wel op een BSD systeem?

De code zelf is vrij standaard, ik gebruik alleen saved user-id, en dat ben ik alleen op Linux nog tegengekomen. Ik zeg d'r eerlijk bij dat ik nog niet echt veel verder gekeken heb

"This module gives the administrator the choice of running scripts inside and outside vhosts under their own UID and GID."

Geldt het niet voor de toegangsrechten van apache voor de betreffende vhost?

Nee, het script draait echt onder de uid/gid waar hij onder moet draaien. Dat kun je instellen per vhost, op basis van de parent dir of op basis van de uid/gid van de file.

[igmar]

deadinspace schreef op 08 februari 2003 @ 22:52:
Ik heb even vluchtig door de source van dat ding gekeken, maar ik zie zo snel niks Linux-specifieks (behalve dan een compile-check).
Volgensmij heeft de schrijver van die module alleen rekening gehouden met Windows en GNU/Linux: "het draait niet op Windows dus alleen op GNU/Linux".

Maareh, wat me meer stoort zijn de waarschuwingen mbt security...

Aangezien ik de auteur ben : Het zal misschien onder Windows werken (maar niet met de huidige code). Het specifieke zit in de setresuid() calls. Geen idee of het op BSD compiled, ik heb geen access op een BSD bak.

[deadinspace]

igmar schreef op 09 February 2003 @ 00:06:
Het specifieke zit in de setresuid() calls.

Oei, setresuid()

code:

CONFORMING TO
       This call is nonstandard.
              
HISTORY
       This  system call was first introduced in HP-UX.  It is available under
       Linux since Linux 2.1.44.  These days it is also found in FreeBSD  (for
       emulation of Linux binaries).

Naja, valt nog te proberen...

[Verwijderd]

Ik zal eens gaan kijken of ik het werkend krijg op de freebsd test bak.

Maar wat ik nog niet snap: bij apache2 kan je een uid en gid per virtual host opgeven. Het child process van apache dat de request voor die virtual host afhandelt krijgt dan die uid en gid. Dus niet alleen de scripts die voor die virtual host worden uitgevoerd worden onder die uid en gid gedaan maar ook apache zelf. Doet jouw script dit ook? Een apache die als root files gaat server vind ik wel heel eng.

[igmar]

Verwijderd schreef op 09 February 2003 @ 16:49:
Ik zal eens gaan kijken of ik het werkend krijg op de freebsd test bak.

Maar wat ik nog niet snap: bij apache2 kan je een uid en gid per virtual host opgeven. Het child process van apache dat de request voor die virtual host afhandelt krijgt dan die uid en gid. Dus niet alleen de scripts die voor die virtual host worden uitgevoerd worden onder die uid en gid gedaan maar ook apache zelf. Doet jouw script dit ook? Een apache die als root files gaat server vind ik wel heel eng.

Het ding wisselt uid / gid aan de hand van de vhost settings, hetzelfde als Apache wat dat betreft.

De root privs zijn alleen nodig ivm de system calls, de childs lopen gewoon onder nobody of onder het UID van de vhost.

[Verwijderd]

Ik heb het uitgetest op m'n test systeem:
FreeBSD 4.7, Apache 1.3.27 (+mod_ssl) en PHP 4.3.0
En het zover ik even snel heb kunnen zien werkt het!
Ik hoefde alleen even #ifndef LINUX enzo weg te halen.

Als ik met top kijk welke processen er draaien is er een httpd van root en een paar anderen van de www user (hoe die daar aan komt weet ik niet want in de apache config file staat nu user root). Maar de virtual hosts werken met de goede user. Als ik de www dir van die user chmod naar 600 dan kan apache er alleen bij als ik die user voor de vhost instel. De PHP functie getmyuid(); geeft ook de voor die vhost ingestelde user id.

Dit snaptje ik niet dus heb ik helemaal uit de configuratie weggelaten:
SuidPolicy user-group | file | document-root | parent-directory

Wat ik wel raar vond is dat wanneer je een PHP file probeert op te roepen waar die vhost geen toegangsrechten tot heeft dan krijg je niet gewoon permission denied maar:
Warning: Unknown(/home/blabla/index.php): failed to create stream: Permission denied in Unknown on line 0
Warning: Unknown(): Failed opening '/home/blabla/index.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0

Maar het wekt dus!!!
Wat moet er nou in PHP en Perl worden ingesteld om het veilig te houden? Het lijkt me dat als een scipt als een niet-root user wordt uitgevoerd dat set*uid() calls sowiso niet kunnen.

[igmar]

Verwijderd schreef op 09 February 2003 @ 23:04:
Ik heb het uitgetest op m'n test systeem:
FreeBSD 4.7, Apache 1.3.27 (+mod_ssl) en PHP 4.3.0
En het zover ik even snel heb kunnen zien werkt het!
Ik hoefde alleen even #ifndef LINUX enzo weg te halen.

Als ik met top kijk welke processen er draaien is er een httpd van root en een paar anderen van de www user (hoe die daar aan komt weet ik niet want in de apache config file staat nu user root).

Die root is nodig aangezien Apache anders zelf een setuid / setgid doet, en dan werkt het niet meer.
mod_suid zet zelf de uid van de children naar www, nobody, etc.

Maar de virtual hosts werken met de goede user. Als ik de www dir van die user chmod naar 600 dan kan apache er alleen bij als ik die user voor de vhost instel. De PHP functie getmyuid(); geeft ook de voor die vhost ingestelde user id.

Dit snaptje ik niet dus heb ik helemaal uit de configuratie weggelaten:
SuidPolicy user-group | file | document-root | parent-directory

Die policy bepaald naar werke user wordt geswitched. Eigenlijk wat bepaald er naar welke UID wordt geswitched.

Wat ik wel raar vond is dat wanneer je een PHP file probeert op te roepen waar die vhost geen toegangsrechten tot heeft dan krijg je niet gewoon permission denied maar:
Warning: Unknown(/home/blabla/index.php): failed to create stream: Permission denied in Unknown on line 0
Warning: Unknown(): Failed opening '/home/blabla/index.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0

Da's een PHP probleem, heeft verder niks met de patch te maken. Het schijnt iets te maken te hebben met de manier waarop een page naar de PHP parser wordt doorgegeven.

Maar het wekt dus!!!
Wat moet er nou in PHP en Perl worden ingesteld om het veilig te houden? Het lijkt me dat als een scipt als een niet-root user wordt uitgevoerd dat set*uid() calls sowiso niet kunnen.

Fout gedacht Je moet iig zorgen dat er geen set*uid() calls kunnen worden uitgevoerd vanuit de apache childs zelf. Ik heb ze gewoon gedisabled in de php.ini