Názory k článku Jailkit: snadné chrootování služeb

No vidite a me se clanek libil. Zase jsem se neco dozvedel. Rozhodne vice, nez z Vasi poznamky.

Akorát ta "režije"

Ahoj,
ale jo, myslim, ze je fajn zminit pomocnika jailkit. Ale rad bych se dozvedel - tady v diskusi - k cemu se vubec chroot pouziva. Jako bezpecnostni reseni to pry neni dobre (ale kdo z nas tady na foru se umi dostat z chrootu?). K cemu to ale jinak je?

Jednou velmi davno jsem pouzil chroot, kdyz jsem bootoval z diskety tomtools a nejak jsem opravoval system. Ale uz si nevybavuju, proc to bylo nutny.

Linux z nejkeho duvodu pritahuje mimo jine male lidi s velkym egem. Nerikam, ze predchozi autor je takovy, jen mi jeho poznamka evokuje tuhle situaci.

Ciste technicky - konstatovani: kazdy rozumny to chape, jen ty nicemu nerozumis a otravujes fora ani neresi dotaz a ani neprispiva k redukci zbytecnych postu na forech.

Ciste sociologicky - takove konstatovani je zpusobem, jak ukazat ve spolecnosti sve nadrazene postaveni. Pritom ve skutecnosti neni k tomuto prohlaseni nutna nijaka znalost a tedy takovy zpusob budovani si spolecenske pozice muze lehce pouzivat i ten, kdo vi, ze existuje prikaz man.

Ciste prakticky - obcas zazni akronym RTFM, ktery ukazuje na nejlepsi odpoved na dany dotaz - v rade pripadu ovsem jde o spis o predani knowhow, ci spise jeste kulturnich hodnot. A na to man nestaci.

... a uzitok predosleho komentara? ;-)

btw.: chroot je jednoducha vec, umozni procesu, aby si 'myslel', ze nejaky adresar (napr. /home/apache) je jeho rootovsky adresar (t.j. adresar /). Proces teda pri pristupe na /bin v skutocnosti pristupuje k /home/apache/bin. Vyhodou je, ze pokial sa kvoli nejakej bezpecnostnej diere pokusi dostat uzivatel k datam mimo povolenej adr. struktury (napr. trik cez ../../tmp), nepodari sa mu to, kdezto, keby spravil ../../tmp v /home/apache bez chroot, dostal by sa do realneho /tmp adresara.

Furt lepší velké ego než porucha osobnosti.

Gratuluji Vam a mate moji podporu! Moc krasne jste vystihl vsechny ty podivny lidi kolem linuxu. Sam se linuxu venuji a je mi smutno, kdyz vidim komentare ve stylu toho na ktery jste reagoval.
VB

Prosil bych nejakou hezkou ukazku nejlepe bez pouziti uzivatele root v chrootu. Diky.

ja pouzivam chroot na beh binarnych aplikacii ktore boli kompilovane na 32bit, sources nie su a casom masiny presli na 64bit... Teoretickym riesenim je aj virtualizacia, ale toto sa mi javi ako lepsie riesenie

Pokud je to na nějaké rozumné distribuci (Debian), lze použít compatibility mód, kdy linker hledá potřebné knihovny v /emul/linux-ia32

Spis jsem myslel to, jak z toho chrootu uniknout.

"If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means," --Alan Cox

Treba tady o tom asi neco bude: http://www.bpfh.net/simes/computing/chroot-break.html

Napriklad kdyz si chces vyzkouset nejakou novou aplikaci a nechces si ji zatim instalovat do sveho systemu. Treba ten priklad s pythonem v clanku.

Ale je fakt, ze v soucasne dobe bych misto chrootu skoro vzdy pouzil virtualni masinu. Myslim, ze cas chrootovani uz odeznel.

Jako bezpečností řešení to je dobré, pokud žádný z procesů nemá oprávnění měnit kořenový adresář (chroot(2)).

pokud nemam dev, tak mknodem si muzu vytvorit deskriptor na disk. Nebo se mylim?

Pokud nejsi v části souborového systému připojeného nodev, tak se nemýlíš. Pokud jsi, tak stačí namountovat tmpfs a vytvořit dev zařízení tam.

Přesně jak jste řekl: o to přece vůbec nejde. chroot slouží na izolaci ve VFS a to je celé. Svůj účel to plní.

Soubor nestačí, musí to být adresář. A Linux v současné verzi chrootování s otevřeným adresářovým deskriptorem mimo budoucí chroot nepovoluje.

Nabootoval jsi z diskety, ale potřeboval jsi pracovat se systémem, jako kdyby běžel -> chroot. K ničemu jiného to prakticky moc není (utéct z chrootu je sice dnes již prakticky nemožné, kernel si to velice hlídá, ale aplikace má úplný přístup k síti a posílání signálů jiným aplikacím a někdy i dev zařízením, což na páchání škod úplně stačí).

Jinak pro zabezpečení aplikací je nejlepší používat virtualizaci, případně systrace.

Anebo zony v Solarisu ;-)

i pres vsechny ty reci o nizke bezpecnosti chrootu, pouzivam na svy malych serverech pro apache modul mod_chroot (http://core.segfault.pl/~hobbit/mod_chroot/), a musim rici, ze dle logu mi resi vetsinu dnesnich automatizovanych utoku na webserver. v error logach se mi to projevuje napriklad nasledne:

sh: line 1: perl: command not found
sh: line 1: id: command not found
sh: line 1: uname: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: id: command not found
sh: line 1: ls: command not found
sh: line 1: uname: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: id: command not found
sh: line 1: which: command not found
sh: line 1: cannot redirect standard input from /dev/null: No such file or directory
sh: line 1: perl: command not found
sh: line 1: uname: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: id: command not found
sh: line 1: which: command not found

i kdyz se mi tam holt nekdo bude chtit dostat, tak se mi tam rozhodne dostane, ale aspon mu muzu jeho prunik trosku stizit, ze?

Tohle spíš vypadá na hodně velkou bugu ve webové aplikaci (neošetřené vstupy?)

jo je to pravdepodobne, protoze na tech serverech je hostovani vetsi mnozstvi php aplikaci, ktery byly psany ruznymi autory na ruznych urovnich znalosti, coz ja neovlivnim. chtel jsem jen poukazat na to, ze kdybych nemel apache v chrootu, tak sem asi o trosku vice v haji zelenym....

Nebylo by lepší použít setuid CGI skripty? Takhle sice útočník nemůže nic udělat s ostatními aplikacemi, ale může zkusit haluzit se soubory ostatních hostovaných.

teoreticky se domnivam, ze ano, ale realne z nekterych velmi historickych duvodu nikoliv... :)