Dotaz: setuid a bash-skripty

[Karel Petranek]

Nejakou dobu si uz s Linuxem hraji (RH7.0), ale nepochopil jsem, proc nemuzu nastavit super-user ID skriptum ?

Vzdyt u exec... () jde o SYSCALL, pro ktery by nemel byt problem, v pripade ze zjisti, ze se pokousime spustit skript a ne ".EXE", spustit BASH s pravy podle s-uid, tedy napr. s ef. pravy root.

Proc jsou skripty proti binarum takto diskriminovaney ?

Musel jsem si napsat v C-cku "obalku" BASH-e ktera si zmeni uid a e-uid podle skriptu a pak teprvce vyvola BASH. Ale pripada mi to krajne nesystemove a hlavne nechapu, proc to nefunguje normalne !

Diky Karel

Odpovědi

[ivok]

http://www.google.com/search?q=shell+scripts+setuid ... a ctete. Doufam, ze anglicky trosku vladnete...

[unchallenger]

zařídit, aby se skript fungoval jako setuid, je obtížné naschvál, a to proto, aby bylo každému jasné, že dělá něco špatně napsat bezpečný setuid skript je téměř nemožné, takže namísto psaní toho skriptu raději pošli svým uživatelům rootovské heslo mailem, vyjde to nastejno a je s tím míň práce

[Karel Petranek]

A v cem konkretne je to tak nebezpecne ? Ve srovnani s binarkami ? Ty mohou delat prece totez, co dela interpret - tedy napr. spoustet dalsi programy.

[unchallenger]

Shell interpretuje příkazy po obskurní několikaúrovňové expanzi ovlivněné několika tucty různých vlivů a nastavení. A pouštění dalších programů je ostatně věc, které bych se v setuid binárce také pokud možno vyhnul (alespoň do dropnutí privilegií).

[RWS]

Nejsem si jisty, ale neni to tim, ze binarka je /bin/bash (nebo /bin/sh), kterej se predava parametr jmeno toho shell skriptu a ten ho jenom interpretuje (stejne jako perl skript)?

Jestli se nepletu, tak pri spusteni skriptu se detekuje, ze to neni binary file, tak se shell mrkne na prvni radek, jestli obsahuje #!.... a kdyz jo, tak se spusti ten prikaz za #! a jemu se preda jmeno toho spustenyho souboru jako parametr, kdyz tam neni #!, tak se tusim pokusi spustit /bin/sh (nebo tak).

Syntaxe podle man bash bash [options] [file] a pro perl perl [programfile], stejne tak pro TCL tcl fileName ...

[unchallenger]

AFAIK v některých Unixech setuid skripty fungují (NetBSD, Solaris, AIX -- hodně staré verze). Takže nejde o to, že by toho nešlo dostáhnout v principu, ale je to věc rozhodnutí, a systémů, kde setuid skripty fungují, myslím postupně ubývá.

[Tomáš Hála]

SUID skripty nejsou dira do systemu, ale otevreny vrata s ceduli "Welcome". Opravdu doporucuju se jim vyhybat, jak to jen jde. Bohuzel stale existuji servery, kde to jeste admini nepochopili a dokonce je nechavaji read for all. (nebudu jmenovat )

[josif]

skript s read4all... on si ten skript jinak uzivatele pousti hodne blbe kdyz na nej nemaji r bit. ale souhlasim, davat suid na skript (davad suid na cokoli co to skutecne absolutne nutne nepotrebuje a co nepozname i pozpatku a o cem nevime ze se proste neda zneuzit) je zhovadilost.

[Hynek (Pichi) Vychodil]

Prdlačky švagrová

kangaroo:~ > cat >test
#!/bin/sh
echo "OK"
kangaroo:~ > chmod 100 test
kangaroo:~ > ls -l test
---x------    1 hynek    instrat        20 čec 24 15:34 test
kangaroo:~ > ./test 
OK
kangaroo:~ > 

Mateřská školka, obor SVID, nebo POSIX compatible OS

[Hynek (Pichi) Vychodil]

Beru zpět. Teorie je hezká věc, ale RH 9 se rozhodl, že vlastník souboru může se svým vlastním souborem cokoli bez ohledu na práva. Výše uvedené není důkazem, protože vlastník může ten soubor přečíst. A skutečně shell script, který nejde přečíst nejde spustit.

[Tomáš Hála]

Stejne je to hloupost. Pokud mluvim o SUID skriptu, tak tim myslim skript spousteny pomoci sudo aj. Samotny SUID bit na skriptu nic neresi, o tom je prece tahle diskuse. No a pokud spoustim skript pomoci sudo, tak nepotrebuji prava na cteni.

[Karel Petranek]

Ja si prave myslim, ze typ souboru urcuje kod SYSCALU exec...() - a ten tedy urci, zda jde o binar -> spusti XOR jde o script -> spusti interpret s parametrem souboru skriptu.

[Hynek (Pichi) Vychodil]

Nemusíš vytvářet žádný vlastní binárku, koukni se na sudo.

[Yaplik (yaplik@atlas.cz)]

de voto ze (ba)sh ma v sobe nastaveny ze kdyz uid != euid tak se pokusi o seteuid( getuid() ); strucne kdyz mu das SUID tak se ho zbavi (SUID funguje)

je to tam z bezpecnostniho důvodu 1. suidnutej bash (backdoor) 2. vyuziti sh exploitem 3. blby uzivatele co se pokouseji psat SUID skripty

vulnerable: 1. musis prepsat celej enviroment (hlavne IFS a PATH) a hlidat si vstupy (coz nijak efektivne nejde); 2. nacteni SUID bashe, (modifikace skriptu, var, env!!), nacteni scriptu, interpretace (bruteforcem za minutku, machine r00ted)

/* example, -r-s--x--x root example.sh */
#!/bin/bash
echo -n "napis text, kterej mam vypsat"
read $TEST
echo $TEST
/* EOF */

zkus zadat "`id`" nebo "zdarec; id" nebo "$PROMENNA" (treba $HESLO nebo $KLIC pro desif apod) etc... (zkus si treba misto id bash, a kdyby to dalo doopravdy SUID tak mas bash s EUID 0, staci c prog setuid(geteuid()) + system("/bin/sh"); a ses kompletni r00t se vsim vsudy (coz takhle zmenit heslo r00ta nebo mu tam hodit r00tkit apod...) cili vykasli se na SUID skripty