Nebojte se SELinuxu – 2 (kontext, politika a pravidla TE) (diskuse)

Diskuse byla administrátory uzamčena.

[Bedňa]

Zaujímalo by ma ako táto bezpečnostná politika žerie strojový čas, napr. si skúšal porovnávať vylistovanie adresára, presun, vymazávanie súborov, zápis, čítanie so suborov a tiež ako je to s bugmi, lebo pri takto sofistikovanej kontrole môže nastať nespočetne veľa chýb, aby to s bezpečnosťou neskončilo horšie ako pri klasickom unixom systéme.

 

[pht]

Shodou okolností o výkonu nedávno vyšel článek na phoronixu: http://www.phoronix.com/scan.php?page=article&item=fedora_debug_selinux&num=1.

Shrnul bych to tak, že samozřejmě nějaké zpoždění tam je, ale to bychom za chvíli taky nemuseli mít ani ten operační systém v protected modu a jet jako za starých časů v unreal režimu pod dosem. Máme dnes 3 GHz mašiny, tak dejme trochu výkonu i bezpečnosti místo kochání se nad 10% load.

Co se týče bezpečnosti, každý kód může s sebou přinést další chyby, ale za ty roky co je SELinux v mainstream jádře, bude určitě ten kód dost dobře odladěn.

[trekker.dk]

Co se týče bezpečnosti, každý kód může s sebou přinést další chyby, ale za ty roky co je SELinux v mainstream jádře, bude určitě ten kód dost dobře odladěn.

Jj, například byla dobře odladěná ta chyba, kdy SELinux zrušil mmap_min_addr, takže umožnil exploit chyby s NULL ukazatelem

Btw. - unreal režim?

[pht]

http://en.wikipedia.org/wiki/Unreal_mode

Jasně, je chyba v jádře, ale proti té Vám nepomůže SELinux ani nic jiného. Zrovna tak Vám nepomůže, pokud někdo vyzradí hesla, nebo pokud má někdo fyzický přístup k počítači. Ve spoustě ostatních případů ale pomůže, a to se počítá. Bezpečnost není binární veličina, jak si řada lidí ráda myslí.

[Radek Hladik]

Já si vždycky vzpomenu na poučku ze školy, že bezpečnost není stav, ale proces

Co se týče výkonu, tak mám pocit, že SELinux dělá poměrně chytré cachování.  Kdysi jsem dělal srovnání 32bit/64bit, PAE/nePAE a i SELinux/NeSELinux. Bohužel hlavní důraz byl na výpočetní výkon a ne souboroové operace, ale i těch tam pár bylo a vliv SELinuxu byl naprosto zanedbatelný až splývající s chybou měření.

[trekker.dk]

Jasně, je chyba v jádře, ale proti té Vám nepomůže SELinux ani nic jiného.

No pozor, ta chyba sice byla v jádře, ale přímo v SELinuxu (taky). SELinux tam něco povoloval, přestože bezpečnostní moduly mají jenom omezovat.

[pht]

Já nějak nechápu, čím se to liší od jiné chyby v jádře.

[xurpha]

Ta chyba tam byla nezávisle na SELinuxu...

[trekker.dk]

Omyl - těch chyb tam bylo víc a jedna byla v SELinuxu.

[pht]

Pokud to chápu dobře, tak ta "chyba v SELinuxu" pouze způsobila, že se odkryla hot fix záplata na jinou chybu. Byl to tedy kombinovaný efekt obou chyb.

[trekker.dk]

Ta chyba v SELinuxu v podstatě umožnila zneužití jiné chyby - zlikvidovala limit na minimální adresu, kterou může uživatelský prostor použít.

[pht]

A co z toho vyvozujete?

[trekker.dk]

ale za ty roky co je SELinux v mainstream jádře, bude určitě ten kód dost dobře odladěn.

Že tohle není tak úplně pravda.

[pht]

Pravdu má každý svou. SELinux je dost dobře odladěn na to, aby pravidelně nezpůsoboval větší bezpečnostní problémy, než jim zamezoval, tudíž aby se ho vyplatilo používat.

[pht]

Abych uvedl Vaše tvrzení na pravou míru (viz články [1] a [2]).

1. Kód SELinuxu jako takový je v pořádku a nic mu nechybí.
2. Celé "omg!!! selinux něco povoluje" je jen o tom, že v systému bez selinux potřebujete roota na namapování 0, v systému se selinux roota a priori nepotřebujete, ale potřebujete to mít povoleno v politice.
3. Některé aplikace (např. wine) potřebují mapovat 0. Na tradičním systému jim můžete dát roota, nebo nastavit mmap_min na 0. V selinuxu nepotřebujete ani jedno, stačí dát konkrétní aplikaci konkrétní právo. Co je lepší?
4. Jedinej problém je v tom, že implicitně se používá politika s typem "unconfined", který dovoluje uživatelům všechno (v rámci normálních UNIX pravidel), tj. i mapovat 0. To ale není problém kódu SELinuxu, ale aplikované politiky. Je to ekvivalent toho, když na neselinuxu dáte každému roota. Kdo má v hlavě aspoň trochu bezpečnostního povědomí, tak tuto politiku nepoužívá.

[1] http://eparis.livejournal.com/606.html

[2] http://lkml.indiana.edu/hypermail/linux/kernel/0907.2/01444.html

[Nicky726]

Co jsem zkoumal nějaké testy, tak v reálném nasazení není téměř žádný dopad a v syntetických testech to byly většinou jen jednotky procent.

Jinak díky za hezký článek.