Názory k článku
Bezpečí s chrootem

Super clanek. Kdyby jste jeste pridal konfiguraci OS, tedy GRSecurity apod. tak by bylo dokonale.

GrSecurity patch by mel byt soucasti SELinux pathe. A v /proc velký pozor na kcore ;)

Jinak moc pekny clanek ;)

> GrSecurity patch by mel byt soucasti SELinux pathe.

Myslím, že toto není až tak úplně pravda. SELinux a GrSecurity jsou konkurenční projekty (stejně jako Medusa nebo RSBAC).

SELinux využívá bezpečnostní "hooky" v jádře - LSM. Pro GrSecurity však nejsou dostačující (viz. http://www.grsecurity.net/lsm.php).

A co nejaky skript/nastroj, ktery dokaze upgradovat chrooty/jaily ne v zavislosti na baliku? Napr. mam chroot s mysqld a hodil by se nastroj, ktery dokaze do chrootu zkopirovat aktualni verze nainstalovaneho mysqld ze systemu, proste jen neco co by dokazalo sjednotit binarky/soubory z hlavniho systemu s chrooty -- popr. by se tak dalo delat i dalsi chrootovany system... Ne vsichni totiz maji Debian...

Zdravím,

asi jsem to nenapsal úplně přesně. To co chcete přesně jailer dělá - tedy jen pro debian. Když řeknete mysqld tak samozřejmě myslíte spoustu programů, které do daného balíku patří. A k tomu i závislosti.

Takže u jaileru řeknete "mysql-server" a všechny závislosti. Můžete ještě říci, že něco nechcete (např. mysql-client) případně chcete něco navíc.

Když jailer pustíte opakovaně jen nahraje aktuální verze balíčků.

Další možností je použití programu "makejail". Ten spustí požadovaný démon a sleduje, které všechny soubory potřebuje. Ty pak umístí do chrootu. Ale z mých zkušeností je to pracnější než jailer - musíte totiž v tomto testovacím režimu provést všechny akce, které budete chtít ve výsledku dělat (např. různe locales, různe timezone, /etc/resolv.conf, ...). Takže v případě debianovské distribuce doporučuji jailer.

S bezpečností chroot bych si tak jistý nebyl. Je to jen jeden stupeň ochrany, celkem slabý.

Jistou úroveň bezpečnosti nabízí chroot prostředí, pouze pokud tam není shell, mount, chmod, mknod, /dev, /proc, a ideálně ani libc (stačí pouze NSS knihovny).

S připojením /dev a /proc chroot prakticky ztrácí význam. Dokonce i jen tehdy, když souborový systém není připojen s "nodev".

Lepší cestou je modifikovat binárku a provádět chroot() v ní. Ovšem pokud zapomeneme otevřený byť jen jediný adresář v době provedení chroot, dá se z chrootu opět utéci. Je nutné provést close() na všechny I/O a chdir() a poté chroot().

Pokud je v chrootu shell, jde polovina bezpečnosti pryč. Vyrobit a spustit shellkód v chrootu není problém. Útěk z chrootu zkomplikuje pouze nutnost mknod(), mount() apod (pokud se podaří).

2) S připojením /dev a /proc jde i zbytek bezpečnosti pryč - útočník proniknuvší do chrootu vidí, co ostatní dělají, je schopen cíleně zabíjet ostatní procesy, vytvářet připojovací body zařízení, a tím chroot bez problémů opustit. Stojí v cestě jen několik nutných bajtů navíc.

Novell AppArmor poskytuje lepší bezpečnost na základě podobného schématu pravidel (seznam povoleného přístupu k vybraným souborům). Je mnohem snadnější na údržbu a méně náročný na kapacitu disku (namísto vícenásobné instalace stačí v jádře omezení přístupu pro určité binárky). Navíc je i bezpečnější, protože pravidla je možné dynamicky zpřísňovat.

jako lepsi chroot se me osvedcil user mode linux, vlastni adresarova struktura se musi vytvaret tak i tak a jde mnohem lip kontrolovat co jde ven a co do vnitr

Ale už zde musí být více aplikací (aby systém vůbec nastartoval) a případně i další nástroje, aby jste se mohl podívat co se v cílovém systému děje. A pokud nemáte patch v hostujícím operačním systému, je opět možné se prolomit i z UML.

Toto řešení není IMHO ani tolik pro oddělení aplikací, jako spíš zákazníků/služeb.

Máte pravdu. Chroot sám o sobě není dokonalý. Pokud útočník získa roota v chrootu, existuje mnoho možností jak se dostat ven.

Proto v chrootu musí být jen nezbytné věci. Proto mám v ukázce zabránění přidání shellu (i když na ní aplikace závisí) Do /dev obvykle přidávám jen /dev/stdout, /dev/stdin, /dev/null, /dev/zero a /dev/log.

Abychom bezpečnost chrootu zvýšili, používáme již zmíněný GrSecurity patch. Ten umožňuje lepší zabezpečení v chrootu (úplný seznam najdete na http://www.grsecurity.net/features.php):

• No attaching shared memory outside of chroot
• No kill outside of chroot
• No ptrace outside of chroot (architecture independent)
• No viewing of any process outside of chroot, even if /proc is mounted
• No mounting or remounting
• No double chroot
• No fchdir out of chroot
• Enforced chdir("/") upon chroot
• No (f)chmod +s
• No mknod
• No sysctl writes
• No raising of scheduler priority
• No connecting to abstract unix domain sockets outside of chroot

A navíc umožňuje:

• /proc restrictions that don't leak information about process owners
• /proc/pid filedescriptor/memory protection

GrSecurity, SELinux a i vámi zmiňovaný Novell AppArmor umožňují omezování přístupu bez kopie pro chroot. Osobně si myslím, že podobné systémy mají budoucnost. Většího nasazení, ovšem dosáhnou až když budou bezpečnostní pravidla součástí instalačních balíčků.

Ono rozběhnout pravidla pro apache + PHP + všechny moduly do PHP, není úplně snadné. Když pak nainstalujete další službu do apache nebo nainstalujete aktualizace, musíte pravidla znovu rozšiřovat. A musíte znovu zjišťovat co všechno je potřeba. Pokud by seznam pravidel byl součástí instalačního balíčku a jen by se povolené aplikace sloučili do jednoho souboru (jak to už je jiná věc). Čímž by se jednoduchost použití dostala na úroveň jaileru a výsledek by byl lepší.

V tomto směru můžeme poděkovat firmě RedHat za integraci do své distribuce. Posunula tuto problematiku zase blíže uživateli.

Bezpečnost je hezká věc, ale vždy si člověk musí klást otázku: Kolik to bude stát, když k průniku dojde. A pokud je vybudování bezpečnosti vyšší než způsobené škody ...

S grsecurity už má chroot o dost silnější ochranu.

Bez něj, chcete-li tam mít /dev/null, musíte povolit dev pro souborový systém. A pokud to povolíte, kód který si tam přidá /dev/hda, je nebezpečně krátký.

---

Sestavit pravidla přístupu či chroot není tak jednoduché, jak to vypadá, a dodaná pravidla často vyžadují úpravy.

Příklad: Identifikace uživatelů vyžaduje NSS knihovny. Pokud se v systému změní typ identifikace, stačí změnit jedinou konfiguraci - /etc/nsswitch.conf. Ovšem u chrootu či AppArmoru je nutné přidat vše, co je potřeba pro novou metodu NSS (což třeba v případě nss_ldap může být více knihoven). Podobně je na tom PAM, nový povolený modul pro apache a další.

a jiz popisovane zakazani mknode ?
pak si tech par radku, ktere vytvori dev od hda ani neskrkne

Pokud Vam jde ciste o webserver, tak tuhle funkcionalitu Vam nabidne Apache mod_security - chroot provede vlastni binarka Apache az po nastartovani a natazeni vsecho potrebneho - v jailu pak nemusite (v extremnim pripade) mit nic krome vlastnich HTML-stranek ...

"Ovšem pokud zapomeneme otevřený byť jen jediný adresář v době provedení chroot, dá se z chrootu opět utéci. Je nutné provést close() na všechny I/O a chdir() a poté chroot()."

K tomu sluzi napriklad grsecurity patch... okrem ineho sposobi trosku rozdielne spravanie chrootu, takze sa z neho neda ujst:-)

Výjimku tvoří pouze naslouchání na TCP/UDP - pan si koleduje, ze to jde v BSD a nezmini, ze to jde i v linuxu.

Děkuji za doplnění. Tohle jsem nevěděl.

linuxjournal zamereny na bezpecnost: http://interactive.linuxjournal.com/issue/143 doporucuji nakouknout, i kdyz ten pred rokem se mi zdal zajimavejsi a lepe informoval o security development edge.

Copak se stane, když si napíšu vhodný modul do jádra a pak ho tam z chrootu zavedu....?

Chroot vám nepomůže. Je to pseudobezpečnostní opatření, které lze obejít stejně snadno, jako jádro bez podpory modulů. Mnoho chyb, které dnes existují, se nachází v různých soubězích v jádře. A jak dostanete roota, tak je chroot i "nemožnost použití modulů" v pytli. Takže nakonec je lepší stejně SELinux a (auditované) omezení aplikací přímo v jádře...

Když už jsme zabředli do té diskuze o zabezpečení chrootem/chrootu, tak bych se docela rád zeptal, co je potřeba na "zneškodnění roota", aby neschodil systém (když pominu chyby v kernelu). Mě napadá pouze zavádění modulů do kernelu, mknod a připojování/odpojování diskových oddílů a virtuálních souborových systémů.

Tak roota rootem dělají v linux (a i v dalších unixech) tzv. capablities (rozsekání práv roota na skupiny). Tato práva se dají odstranit pomocí příkazu 'lcap'.

Pomocí něj lze tedy z roota udělat běžného uživatele. Případně i další bezpečnostní subsytémy (např. dříve jmenovaný SELinux) umožňuje capablities nastavovat.

lcap umožňuje nastavovat v Linuxu tyto capabilities:

   0) *CAP_CHOWN                   1) *CAP_DAC_OVERRIDE
   2) *CAP_DAC_READ_SEARCH         3) *CAP_FOWNER
   4) *CAP_FSETID                  5) *CAP_KILL
   6) *CAP_SETGID                  7) *CAP_SETUID
   8)  CAP_SETPCAP                 9) *CAP_LINUX_IMMUTABLE
  10) *CAP_NET_BIND_SERVICE       11) *CAP_NET_BROADCAST
  12) *CAP_NET_ADMIN              13) *CAP_NET_RAW
  14) *CAP_IPC_LOCK               15) *CAP_IPC_OWNER
  16) *CAP_SYS_MODULE             17) *CAP_SYS_RAWIO
  18) *CAP_SYS_CHROOT             19) *CAP_SYS_PTRACE
  20) *CAP_SYS_PACCT              21) *CAP_SYS_ADMIN
  22) *CAP_SYS_BOOT               23) *CAP_SYS_NICE
  24) *CAP_SYS_RESOURCE           25) *CAP_SYS_TIME
  26) *CAP_SYS_TTY_CONFIG