Názory k článku Bezpečí s chrootem
-
Petr Ferschmann (neregistrovaný)> 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... -
Petr Ferschmann (neregistrovaný)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. -
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:-) -
_ (neregistrovaný)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.
-
Milan Keršláger (neregistrovaný)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...
-
Majkls (neregistrovaný)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ů.
-
Petr Ferschmann (neregistrovaný)
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
