Изпечатай

[gat3way]

http://lwn.net/Articles/509438/

Най-важното нещо в случаят е че това нещо е намерило място в lwn, защото не казва ама абсолютно нищо ново. Да не говорим че част от аргументите са малоумни.

На второ четене обаче, като се замисля, има недоизпипани неща. Примерно защо процес confine-нат в httpd_t  трябва да може да чете /etc/passwd? Не че има някакво значение, но не мога да се сетя за истинска причина.

Мисля, че има едни хубави пари в правенето на custom selinux policy-та. Същевременно самия selinux има празни места, примерно няма начин (аз поне не се сещам, макар че не съм се занимавал отдавна) да правиш per-syscall ограничения и следствието е че PHP шела може да си разглежда съдържанието на директориите благодарение на вградени PHP функции, докато примерно /bin/ls няма как да се изпълни заради label-а му. Доста тъпо.

[shoshon]

Примерно защо процес confine-нат в httpd_t  трябва да може да чете /etc/passwd? Не че има някакво значение, но не мога да се сетя за истинска причина.

Не знам...

[root@ivan-laptop ivan]# chmod 600 /etc/passwd

ssh...

[I have no name!@ivan-laptop ~]$ whoami
whoami: cannot find name for user ID 1000

ll /home

[I have no name!@ivan-laptop ~]$ ll /home
total 36
drwx------. 61 1001 group1  4096 Aug  5 03:05 user1
drwx--x---+ 51 1000 group2      4096 Aug  5 07:09user2
drwx------.  2    0 root     16384 Mar 13 16:48 lost+found
drwxrws--t.  3    0 root        4096 Aug  3 19:20 Private
drwxrwsr-x.  6    0 users     4096 Jul 29 00:07 Public
[I have no name!@ivan-laptop ~]$

Всъщност може би за самия httpd процес няма особено значение, но фактът, че системата е проектирана така, че /etc/passwd да е четим от всички може да се отрази неблагоприятно, ако изведнъж спре да бъде вярно. За 99% от Web сървърите сигурно няма изобщо значение, но има други хора със собствени и "особени" приложениия... Знаеш ли
httpd.conf
user = webuser ## Oops! No such user!

примерно няма начин да правиш per-syscall ограничения и следствието е че PHP шела може да си разглежда съдържанието на директориите благодарение на вградени PHP функции,

Това е доста встрани от дезайна на проекта. До колкото аз разбирам идеята е да има role-базиран достъп до определен файл (SELinux държи контекста в атрибути на файла на файловатра система) за да може един вид да оцениш всеки сървиз колко му вярваш. На кратко казано според мен:
 - кои системни извиквания? как ще се зададат права на системни извиквания? Ако е само read/write/open/creat/exec* малко дублиране става...
 -  а ако няма SELinux какво става с кода? Правим проверки за нещо, което не съществува? И всеки път така...

Процес, който няма права за malloc() ?
Каква ще е прозиводителността ако за всяко системно извикване, трябва да се проверяват параметрите, с които се изпълнява?

[gat3way]

Не е толкова встрани от идеята. SELinux е базиран върху LSM hook-ове, каквито има на всеки syscall. Интерфейса, който се предоставя на потребителя представя нещата така че да си имаш вземане-даване предимно с етикети на файлова система и права за разни IPC операции (предимно със сокети). Алтернативно някои syscall-ове могат да се контролират наистина, понякога това е ужасно грубо. Примерно ioctl - там има много "от-до", но или можеш или не можеш да го правиш върху някой device. Въпреки всичко не пречеше да се направи per-syscall. Така много лесно се "patch-ват" разни kernel експлойти за нови кернелски системни функции, както беше случая с vmsplice навремето.


Иначе malloc() не е системно повикване. malloc() може евентуално да викне syscall-а brk() за да мапне още памет в адресното пространство на процеса, но може и да не го направи.

Що се отнася до производителността - проверки винаги има. Особено при syscall-ове които по дизайн включват като входни аргументи - указател към userspace-ска памет. Там има доста проверки, с или без SELinux.