Jaderné noviny – 23. 9. 2009 (diskuse)

[trekker.dk]

Nedal jsem to přímo do článku, ale pro jistotu: Jaderné noviny jsou překlad, takže pokud byste někdo chtěli posílat dotazy na jaderné vývojáře, pak buď původnímu autorovi nebo na adresu uvedenou v článku Gregovi KH. (Pochopitelně v angličtině)

[Martincek]

Jak to vypadá s tím AppArmor? Chci se naučit nějaké bezpečnostní rozšíření jádra a alternativou je už jen SELinux. A ten je opravdu složitý a jak říkají i někteří odborníci - jeho možnosti nastavení jsou tak jemné, že to jen tak někdo nezvládne. A upgrade každého programu se pak stává bolestnou záležitostí.

AppArmor přitom vypadá úžasně jednoduše a věřím, že i když je založen na cestách k souborům, třeba díry v php by mohl ochránit docela dobře.

Jenže jestli ho vyhodí z jádra, tak je konec. Přitom Ubuntu zvolilo AppArmor jako svoji hlavní bezpečnostní technologii.

Používá to někdo? Má to budoucnost?

[ivan]

Me prijde SELINUX docela nebezpecnej, protoze pouziva extended atributy filesystemu. Chapu, ze je z urcityho pohledu optimalni pristup, ale sprava takovyho systemu muze byt nebezpecna. Nekdy staci tohle(anebo neco podobnyho):

cp /etc/shadow /etc/shadow.bak
..
cp /etc/shadow.bak /etc/shadow

a jste v ... - novy shadow soubor nema spravne extended atributy.

[Dramon]

root si holt musí dávat pozor co dělá. Ale stejným způsobem si každý musí hlídat ACL, pokud se používají. A občas spuštěný restorecon systému také neublíží :)
Pokud by člověk chtěl systém založený na názvu souboru, může se v rámci SELinuxu tento název dát do konfiguračního souboru démona restorecond a on mu to pohlídá.

[asdf]

SELinux zase tak slozity neni. Vypilovat konfiguraci, aby delal vse, co je potreba, muze byt pracne, ale pridani nekolika jednoduchych pravidel je docela snadne. Dobrou dokumentaci je
http://www.root.cz/knihy/ceska-dokumentace-pro-selinux/,
http://www.root.cz/serialy/jak-spravne-na-selinux/

[Karry]

...každý ví, že ioctl jsou ošklivá a zlá...

Já to nevím... Co je na nich tak zlého? Vždyť se používají všude... Co by se místo nich mělo používat?

[cronin]

Co je na nich tak zlého? Vždyť se používají všude.

Prave to je na nich zle - su vsemocnym mechanizmom ako zasahovat do vsetkeho mozneho, a to bez spolocneho dizajnu, zjavnej semantiky a cohokolvek co by sa dalo nazvat navrhnutym rozhranim. Same o sebe povodne vznikli len ako workaround, ktory metastazoval do celeho kernelu.

[Karry]

su vsemocnym mechanizmom ako zasahovat do vsetkeho mozneho

bezesporu...

Koukni na tento kousek:

unsigned long int value;
fd = syscall(SYS_open, devf, O_RDONLY);
ioctl(fd,VIDIOC_G_CTRL,&value);
close(fd);

Je to kus kódu z použití V4L API. Přijde ti tohle špatně navržené? Jak tohle udělat lépe, aby se pokud možno zachovala jednoduchost?

[petr_p]

V mikrojádrech je tento způsob zcela normální, protože prakticky všechny zbytné „služby systému“ jsou formálně zprávy zasílané mezi procesy. V podstatě je to jen otázka curryfikace – jestli je název služby vestavěn do názvu funkce nebo veden jako argument.

[ivan]

Mel by na to byt zvlastni syscall. unixy maji obecne minimum syscallu(narozdil od woken). Chybejici syscally se nahrazuji ioctl. Pro samostnou fukcionalitu aplikace to asi neni problem. Co kdyz prozenete svuj program nejakym analyzatorem a ten vam rekne ze jste stravil 80% casu cekanim na iotl? Jaky z toho udelate zaver? Zrovna to V4L proslo nejakym vyvojem - ioctl umoznuje snadnou zmenu rozhrani ovladace, beze zmeny zbytku kernelu a userspace knihoven. To nemusi byt zrovna vyhodne pro uzivatele.