Re: pld na hosting PHP - jak rozdzielacie klientów?
Jacek Osiecki
joshua w hybrid.pl
Pią, 12 Gru 2008, 14:13:29 CET
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 joshua w ceti.pl GG:3828944
"To nie logika, to polityka"
(c) Kabaret pod Wyrwigroszem 2006
Więcej informacji o liście dyskusyjnej pld-users-pl