Vlákno názorů k článku Bezpečí s chrootem od Stanislav Brabec - S bezpečností chroot bych si tak jistý nebyl....
-
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. -
Petr Ferschmann (neregistrovaný)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. -
Petr Ferschmann (neregistrovaný)
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ší. -
hohoho (neregistrovaný)"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:-)
