Ako by to vyzeralo so SELinuxom:
Utocnik by sice mohol nahrat skript niekam, ale uz by mu nemohol dat pravo na spustenie.
Druha vec je, ak sa da napr. cez GET premennu nejaky iny skript prinutit, aby utocnikov skript includol (AFAIK bohuzial celkom bezna technika napadania blbo napisanych skriptov). Specialne ak by v politike bolo pre rolu http servera povolene citanie /var/http/nejaky/adresar/tmp/*, tak to holt moc nepomoze (utocnikov skript sa includne a spusti). SELinux by dokazal zabranit exec()u, ale v pripade includovania sa otvara ten utocnikov skript len na citanie (co je zase podobne ako obycajne citanie nejakych dat, tj. z pohladu SELinuxu neodlisitelne).
Hlavne: politiku si musi admin upravit sam, lebo iba on vie, kto kde ma sahat, defaultna distribucna politika pre apache samozrejme nemoze tusit, ake skripty bude spustat. Samozrejme takato bezpecnost je dost narocna/draha.
Mimochodom, celkom dobry kompromis medzi zlozitostou RBAC a "benevolentnostou" klasickych distribucii je grsecurity bez RBAC. Je to lahkotonaznejsie nez plne RBAC, ale clovek sa z administrovania nezblazni. Mam pocit, ze to navrhovali stylom, ze zobrali najbeznejsie zranitelnosti a urobili proti nim nejake obrany (samozrejme to neni nepriestrelne), napr.:
-spominany non-executable stack, ASLR, odstranenie "zbytocnych" informacii ako process memory maps, neviditelne cudzie procesy apod. (tj. hlavne proti buffer overflow)
-trusted path execution, povoli exec() len z niektorych ciest (zase v pripade includovania utocnikovho skriptu ale nepomoze)
-je mozne zakazat urcitym userom vytvarat nove sockety (jak "klientske", tak "serverove")
-vselijake moznosti auditu
-zamerne disablovanie "featur" typu /dev/mem, /dev/kmem, ..., pri disablovani LKM je zarootkitenie potom naozaj hodne tazkou ulohou
-dalej viz. http://www.grsecurity.net/features.php
Holt ale blbo napisany skript je blbo napisany skript - ziadny RBAC system napr. nezabrani SQL injection a tomu spominanemu includovaniu, ak utocnik tam uz ten svoj skript raz uploadne.
Názor k článku
Proč byste měli chtít SELinux?
