pld na hosting PHP - jak rozdzielacie klientów?

[Wojciech Błaszkowski]

Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał:

> >>> 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...

Przykład pierwszy z brzegu:
Dziurawa joomla, za pomocą której odpalą Ci perlowe skrypty biegające po 
serwerze i zjadające zasoby. Problem dla wszystkich użytkowników.

> >> 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?
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ąć...

Masz 30 wirtualek - jest OK.
Masz 30.000 wirtualek - sam będziesz miał problem żeby to ogarnąć. Dodaj do 
tego płace userów o "udziwnienia" jakie stosujesz.

Chociaż patrząc z drugiej strony zalety jakie podajesz są ciekawe :)

> >> 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-includ
> >ing-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).
Niewłaściwie użyta - poblokuje Ci to czego nie chcesz.

Apparmor możesz ustawić tak, żeby zapisywał do logu operacje dostępów do 
zasobów, które uznałeś za niedozwolone, bez blokowania dostępu. Na takiej 
podstawie patrzysz, czy przyjęte przez Ciebie regułki są poprawne.

Nie ukrywam, że jest z tym trochę zabawy, ale na prawdę warto. IMO najlepiej 
temat zna autor bloga http://www.maven.pl/

> 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.

Kij, którym machasz ma 2 końce. Pierwszy to bezpieczeństwo serwera, drugi to 
wygoda użytkowników. Temat staary jak świat.

> >> 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.

hmm.. dodatkowo, w php.ini:

disable_functions = dl
enable_dl = Off

-- 
Pozdrawiam, Best regards, Mit freundlichen Grüßen,

Wojciech "Wojtosz" Błaszkowski
www.blaszkowski.com
GSM: +48 600 197 207
JID: wojtosz w jabber.biz.pl