On Fri, 12 Dec 2008, Wojciech Błaszkowski wrote:
Witam,
[...]
Bardziej martwiłbym się tym, że jeśli klient będzie marudził o
safe_mode=off w php.ini bo nie może zainstalować sobie osCommerce (lub
O safe_mode nie ma mowy, bo po pierwsze wiążą się z nim dodatkowe problemy
safe_mode to przykład. Chodzi mi o bezpieczeństwo samych aplikacji odpalanych
na Twojej maszynie. Ty możesz zabezpieczyć serwer, ale ludzie będą tam
wrzucać różne bzdury.
Co masz na myśli pisząc o "różnych bzdurach"? Jeśli klient może zaszkodzić
wyłącznie sobie, to w zasadzie nie jest to problem...
Ale co konkretnie da mi AppArmor - to, że apache nie będzie mógł odczytać
zawartości /home/clients? Przecież to mogę zrobić uprawnieniami 111 dla
/home/clients... Jak ktoś ma stronę duperele.pl i widzi że jest w
/home/clients/duperele, to domyśli się że bzdury.pl są w
/home/clients/bzdury - i "zabezpieczenie" na nic. Sprawę rozwiązuje moje
dodanie losowego katalogu po drodze - czyli /home/clients/<hash>/nazwa -
Security by obscurity.
Sure? Jeśli znajomość zgadnięcia klucza md5 jest konieczna by wejść do
jakiegoś katalogu, to równie dobrze można za "security by obscurity" uznać
zabezpieczenie hasłem - bo przecież wystarczy je zgadnąć...
czy w takim układzie AppArmor może mi cokolwiek dać, poza zabronieniem
userowi apache dostępu do czegokolwiek poza /home/clients?
Tak. Da i to więcej niż przypuszczasz. Dla każdego $login dajesz osobne
regułki.
http://www.youtube.com/watch?v=EgrfmSm0NWs
http://www.maven.pl/2006/12/13/apparmor-protection-for-your-apache-including-mod_php-mod_python-and-others/
Brzmi ciekawie, natomiast o tyle boję się zabawy z AppArmorem że jest to
kolejna zabawka w kernelu która może albo zdestabilizować serwer albo
sprawić że coś przestanie działać (mimo że nie powinno). O ile ufam jeszcze
grsecurity (i tak z ograniczeniami - np. potrafiło zablokować sockety dla
wszystkich użytkowników mimo że nie miało tego robić) to dokładanie
dodatkowego takiego niepewnego klocka średni mi się uśmiecha.
Bo zakładam że
system sam w sobie jest bezpieczny i nie ma możliwości by ktoś skryptem PHP
namieszał gdziekolwiek...
DUŻY błąd.
Dodatkowe założenia: noexec wszędzie gdzie php ma prawo zapisu, grsecurity,
aktualny kernel, aktualne pakiety.
Pozdrawiam,
--
Jacek Osiecki [email protected] GG:3828944
"To nie logika, to polityka"
(c) Kabaret pod Wyrwigroszem 2006
_______________________________________________
pld-users-pl mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
