Re: pld na hosting PHP - jak rozdzielacie klientów?
On Tue, 16 Dec 2008, Arkadiusz Rdest wrote: Wojciech Błaszkowski wrote: Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał: Zatem login ma możliwość wglądu wyłącznie do własnych $domena. Config dla apache generowany również z bazy danych, co załatwia sprawę m.in. DocumentRoot. sie podalcze. wszytko ok. generowanie z bazy itp. tez mam tak zrobione. ale jak rozwiazales sprawe reloadow apacha przy dodawaniu nowych vhostow? niestety teraz co kilka godzin musze zrobic relaod (wystarczy graceful) apacha zeby zalapal nowe vhosty. A co bolą graceful restarty apache'a, pod warunkiem że konfig nie został spieprzony? Ja to robię/mam zamiar robić tak: ultraprymitywny demon w bashu, podtrzymywany przy życiu przez inita, raz na minutę sprawdza czy w bazie mysql nie doszedł nowy vhost. Jak doszedł - to generuje na nowo definicje virtualhostów i odpala /etc/init.d/httpd reload Jakieś przeciwskazania dla takiego rozwiązania? Stosuję z powodzeniem do maszynek zarządzających sporą siecią - tam akurat do regułek proxy i iptables, ale zasada działania identyczna... niestety ze wzgledu na uzywanie mod_fastcgi i osobnych konfigow php.ini dla userow nie moge uzyc np. mod_rewrite'a do dynamicznego generowania vhostow. Póki co chciałbym uniknąć używania php jako cgi/fastcgi :) masz to jakos lepiej/sensowniej roziwazane niz cokilkugodzinne reloady? jw. Niby nie zabezpiecza to fizycznie przed wejściem do sąsiada, teoretycznie wystarczy się wstrzelić w nazwę katalogu (oczywiście katalog w /home/clients jest generowany dla każdego klienta) ale biorąc pod uwagę ilość możliwych kombinacji to jest to mało prawdopodobne. a jesli ktos/cos odczyta /etc/passwd? albo jesli nie masz w php zablokowanej funkcji posix_getpwuid? to wszytkie homediry jak na dloni :) A 400 na /etc/passwd, albo apparmor? P.S. Nie wiem co jest, dałbym głowę że już pisałem tę odpowiedź ale chyba mi się to śniło :) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
Witam, Zatem login ma możliwość wglądu wyłącznie do własnych $domena. Config dla apache generowany również z bazy danych, co załatwia sprawę m.in. DocumentRoot. sie podalcze. Po to jest lista dyskusyjna ;-) wszytko ok. generowanie z bazy itp. tez mam tak zrobione. ale jak rozwiazales sprawe reloadow apacha przy dodawaniu nowych vhostow? niestety teraz co kilka godzin musze zrobic relaod (wystarczy graceful) apacha zeby zalapal nowe vhosty. niestety ze wzgledu na uzywanie mod_fastcgi i osobnych konfigow php.ini dla userow nie moge uzyc np. mod_rewrite'a do dynamicznego generowania vhostow. masz to jakos lepiej/sensowniej roziwazane niz cokilkugodzinne reloady? Niestety, nie. Restarty apache są. Również jestem otwarty na rozwiązanie tego _problemu_. Niby nie zabezpiecza to fizycznie przed wejściem do sąsiada, teoretycznie wystarczy się wstrzelić w nazwę katalogu (oczywiście katalog w /home/clients jest generowany dla każdego klienta) ale biorąc pod uwagę ilość możliwych kombinacji to jest to mało prawdopodobne. a jesli ktos/cos odczyta /etc/passwd? albo jesli nie masz w php zablokowanej funkcji posix_getpwuid? to wszytkie homediry jak na dloni :) AppArmor zabrania dostępu do (tych) wybranych plików. Bedę o tym trąbił do upadłego :) -- Pozdrawiam, Best regards, Mit freundlichen Grüßen, Wojciech Wojtosz Błaszkowski www.blaszkowski.com GSM: +48 600 197 207 JID: wojt...@jabber.biz.pl ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
On Tuesday 16 of December 2008 23:34:45 Wojciech Błaszkowski wrote: Witam, Zatem login ma możliwość wglądu wyłącznie do własnych $domena. Config dla apache generowany również z bazy danych, co załatwia sprawę m.in. DocumentRoot. sie podalcze. Po to jest lista dyskusyjna ;-) wszytko ok. generowanie z bazy itp. tez mam tak zrobione. ale jak rozwiazales sprawe reloadow apacha przy dodawaniu nowych vhostow? niestety teraz co kilka godzin musze zrobic relaod (wystarczy graceful) apacha zeby zalapal nowe vhosty. niestety ze wzgledu na uzywanie mod_fastcgi i osobnych konfigow php.ini dla userow nie moge uzyc np. mod_rewrite'a do dynamicznego generowania vhostow. masz to jakos lepiej/sensowniej roziwazane niz cokilkugodzinne reloady? Niestety, nie. Restarty apache są. Również jestem otwarty na rozwiązanie tego _problemu_. nie załatwia Wam sprawy mod_vhost_alias? To działa tak, że jak użytkownik zarząda host: example.org, to apache szuka plików w .../e/x/example.org Dodanie nowej domeny sprowadza się do utworzenia odpowiedniego katalogu. Oczywiście żadne restarty indiańca nie są potrzebne. -- .Pozdrawiam, . . Pawel Zuzelski. . jid:p...@touk.pl. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał: Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? BTW, chcesz trzymać MySQL i Apache na jednej maszynie ? Jeśli tak - odradzam. Zerknij na http://www.blaszkowski.com/2007/05/28/webhosting-wprowadzenie/ -- Pozdrawiam, Best regards, Mit freundlichen Grüßen, Wojciech Wojtosz Błaszkowski ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
On Sun, 14 Dec 2008, Piotr Pawłow wrote: On piątek, 12 grudnia 2008, Jacek Osiecki wrote: 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ąć... Ale czy faktycznie trzeba zgadywać nazwę katalogu? Może ją wyciągnąć z /proc/$pid/fd procesu sąsiada? Albo zrobić strace na procesie sąsiada? Biorąc pod uwagę że: - nie ma w ogóle dostępu shellowego dla userów - jest grsecurity które nawet userom shellowym nie daje dostępu do /proc/cudzypid, nie mówiąc o php, - jest ustawione open_basedir na katalog domowy usera to chyba nici ze strace'a i innych cyrków z /proc A jeśli nawet trzeba zgadywać, to można spróbować wykorzystać fakt, że próba wejścia do katalogu może zająć różną ilość czasu zależnie od tego ile znaków pasuje, a tym samym znacznie ograniczyć ilość potrzebnych prób. Nie sądzę by różnice - jeśli w ogóle są - były na poziomie mierzalnym dla PHPa, który w końcu jest językiem interpretowanym... Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
Witam, Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał: Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? BTW, chcesz trzymać MySQL i Apache na jednej maszynie ? Jeśli tak - odradzam. Zerknij na http://www.blaszkowski.com/2007/05/28/webhosting-wprowadzenie/ w vserverkach mozna ograniczyc zasoby oraz odseparowac avg-load miedzy kontekstami (detale podrzucily magiki z #pld). # cat /etc/vservers/$guest/flags virt_load Dodatkowo daję: sched_hard virt_mem virt_uptime virt_cpu virt_time hide_netif dzieki temu apache nie wylaczy mysqla i nie trzeba dostawiac pudelek w serwerowni. Ciekawostka: Virtuozzo pozwala zmigrować pomiędzy maszynami vserver bez jego wyłączania (sic!). Niestety, pomimo próźb kierowanych do Parallels (wówczas SWSoft) PLD nie jest i na dzień dzisiejszy nie będzie wspieraną przez nich distro :( -- Pozdrawiam, Best regards, Mit freundlichen Grüßen, Wojciech Wojtosz Błaszkowski www.blaszkowski.com GSM: +48 600 197 207 JID: wojt...@jabber.biz.pl ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów ?
Dnia Fri, 12 Dec 2008 10:23:26 +0100 (CET) Jacek Osiecki jos...@hybrid.pl napisał(a): Subject: pld na hosting PHP - jak rozdzielacie klientów? http://www.telana.com/peruser.php [r...@dfs ~]# grep MPM /etc/sysconfig/httpd # choose MPM #HTTPD_MPM=prefork HTTPD_MPM=peruser ..mozesz nawet walnac kazdemu userowi chroot'a. peruser ma tez swoje wady ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
On piątek, 12 grudnia 2008, Jacek Osiecki wrote: 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ąć... Ale czy faktycznie trzeba zgadywać nazwę katalogu? Może ją wyciągnąć z /proc/$pid/fd procesu sąsiada? Albo zrobić strace na procesie sąsiada? A jeśli nawet trzeba zgadywać, to można spróbować wykorzystać fakt, że próba wejścia do katalogu może zająć różną ilość czasu zależnie od tego ile znaków pasuje, a tym samym znacznie ograniczyć ilość potrzebnych prób. Pozdrawiam ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów ?
Piotr Pawłow wrote: Ale czy faktycznie trzeba zgadywać nazwę katalogu? Może ją wyciągnąć z /proc/$pid/fd procesu sąsiada? Albo zrobić strace na procesie sąsiada? strace i proc raczej wymagają sporych uprawnień. A jeśli nawet trzeba zgadywać, to można spróbować wykorzystać fakt, że próba wejścia do katalogu może zająć różną ilość czasu zależnie od tego ile znaków pasuje, a tym samym znacznie ograniczyć ilość potrzebnych prób. Nie wydaje mi się, zeby katalogi były realizowane jako linear search we współczesnych systemach plików, a szybkość hashowania nie zależy od ilości pasujących znaków. -- regards, Jakub Piotr Cłapa ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
pld na hosting PHP - jak rozdzielacie klientów?
Witam, Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? Chodzi o to, by uniemożliwić klientom zaglądanie do katalogów sąsiadów... Na razie mam to rozwiązane tak: - vsftpd, klient po zalogowaniu ma HOME jako / - każdy klient ma HOME w katalogu: /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta, przy czym /home/clients ma usera root.root i 711 Niby nie zabezpiecza to fizycznie przed wejściem do sąsiada, teoretycznie wystarczy się wstrzelić w nazwę katalogu (oczywiście katalog w /home/clients jest generowany dla każdego klienta) ale biorąc pod uwagę ilość możliwych kombinacji to jest to mało prawdopodobne. Pierwszy problem to to że samo rozwiązanie nie jest zbyt eleganckie, jak ktoś chce sobie podawać ścieżki bezwzględne to będzie miał problem (oczywiście klienci nie dostają shella). Drugi problem to mała wygoda dla mnie - co prawda jak jestem zalogowany na serwerze to wystarczy wejść cd ~nazwaklienta, ale jak np. mam uniwersalnego usera ftp do wuwy to nijak nie dotrę do katalogu klienta - muszę najpierw sprawdzić jego $HOME w /etc/passwd... Najfajniej by było zrobić tak, żeby php widziało $HOME jako / - tak jak to jest rozwiązane bodajże w home.pl... tylko że oni mają własnoręcznie napisany serwer www :) Jak Wy to robicie? Wiem że można np. zrobić wszędzie uruchamianie PHP jako CGI i ustawienie takich uprawnień żeby jeden user nie miał szans zajrzeć do innego, ale to się wiąże ze znacznym spowolnieniem działania PHPa na co raczej nie mogę sobie pozwolić. Jakieś inne pomysły? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał: Witam, Hej, Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? Chodzi o to, by uniemożliwić klientom zaglądanie do katalogów sąsiadów... Na razie mam to rozwiązane tak: - vsftpd, klient po zalogowaniu ma HOME jako / - każdy klient ma HOME w katalogu: /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta, przy czym /home/clients ma usera root.root i 711 Uzywam pure-ftpd. Loginy zakładane są przez interfejs php i trzymane w bazie danych. pure-ftpd pobiera sobie te dane i umozliwia logowanie. Flaga ChrootEveryone ustawiona na yes. Mamy: /home/vhosts/$login/$domena Zatem login ma możliwość wglądu wyłącznie do własnych $domena. Config dla apache generowany również z bazy danych, co załatwia sprawę m.in. DocumentRoot. Niby nie zabezpiecza to fizycznie przed wejściem do sąsiada, teoretycznie wystarczy się wstrzelić w nazwę katalogu (oczywiście katalog w /home/clients jest generowany dla każdego klienta) ale biorąc pod uwagę ilość możliwych kombinacji to jest to mało prawdopodobne. 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 inny powód) to mu się to da. Jeśli już mu się da, to może sobie zrobić skrypt myszkujący po /home/vhosts/ który to skrypt będzie szukał config.php i zapisywał/wysyłał gdzieś jego zawartość. Rozwiązanie AppArmor. Pierwszy problem to to że samo rozwiązanie nie jest zbyt eleganckie, jak ktoś chce sobie podawać ścieżki bezwzględne to będzie miał problem (oczywiście klienci nie dostają shella). Drugi problem to mała wygoda dla mnie - co prawda jak jestem zalogowany na serwerze to wystarczy wejść cd ~nazwaklienta, ale jak np. mam uniwersalnego usera ftp do wuwy to nijak nie dotrę do katalogu klienta - muszę najpierw sprawdzić jego $HOME w /etc/passwd... Najfajniej by było zrobić tak, żeby php widziało $HOME jako / - tak jak to jest rozwiązane bodajże w home.pl... tylko że oni mają własnoręcznie napisany serwer www :) Jak Wy to robicie? j.w. Wiem że można np. zrobić wszędzie uruchamianie PHP jako CGI i ustawienie takich uprawnień żeby jeden user nie miał szans zajrzeć do innego, ale to się wiąże ze znacznym spowolnieniem działania PHPa na co raczej nie mogę sobie pozwolić. Jakieś inne pomysły? Pozdrawiam, -- Pozdrawiam, Best regards, Mit freundlichen Grüßen, Wojciech Wojtosz Błaszkowski ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
On Fri, 12 Dec 2008, Wojciech Błaszkowski wrote: Dnia piątek 12 grudzień 2008, Jacek Osiecki napisał: Witam, Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? Chodzi o to, by uniemożliwić klientom zaglądanie do katalogów sąsiadów... Uzywam pure-ftpd. Loginy zakładane są przez interfejs php i trzymane w bazie danych. pure-ftpd pobiera sobie te dane i umozliwia logowanie. Flaga ChrootEveryone ustawiona na yes. To akurat nie problem, w vsftpd mam to samo :) Niedługo przesiądę się na proftpd, bo tam mam już ładnie ujęte wszystkie konta ftp w mysqlu i obsługę quoty również przy użyciu wpisów w mysql - wtedy bym mógł w ogóle zrezygnować z różnych kont rzeczywistych dla poszczególnych userów. Niby nie zabezpiecza to fizycznie przed wejściem do sąsiada, teoretycznie wystarczy się wstrzelić w nazwę katalogu (oczywiście katalog w /home/clients jest generowany dla każdego klienta) ale biorąc pod uwagę ilość możliwych kombinacji to jest to mało prawdopodobne. 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 inny powód) to mu się to da. Jeśli już mu się da, to może sobie zrobić skrypt myszkujący po /home/vhosts/ który to skrypt będzie szukał config.php i zapisywał/wysyłał gdzieś jego zawartość. O safe_mode nie ma mowy, bo po pierwsze wiążą się z nim dodatkowe problemy a po drugie w php6 już nie będzie safe_mode (nie mogę się nigdzie doczytać co chcą dać w zamian). Rozwiązanie AppArmor. 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 - czy w takim układzie AppArmor może mi cokolwiek dać, poza zabronieniem userowi apache dostępu do czegokolwiek poza /home/clients? Bo zakładam że system sam w sobie jest bezpieczny i nie ma możliwości by ktoś skryptem PHP namieszał gdziekolwiek... Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
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 inny powód) to mu się to da. Jeśli już mu się da, to może sobie zrobić skrypt myszkujący po /home/vhosts/ który to skrypt będzie szukał config.php i zapisywał/wysyłał gdzieś jego zawartość. O safe_mode nie ma mowy, bo po pierwsze wiążą się z nim dodatkowe problemy a po drugie w php6 już nie będzie safe_mode (nie mogę się nigdzie doczytać co chcą dać w zamian). 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. Rozwiązanie AppArmor. 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. 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/ 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. -- Pozdrawiam, Best regards, Mit freundlichen Grüßen, Wojciech Wojtosz Błaszkowski www.blaszkowski.com GSM: +48 600 197 207 JID: wojt...@jabber.biz.pl ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
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 jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
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: wojt...@jabber.biz.pl ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów ?
Dnia 2008-12-12, o godz. 10:23:26 Jacek Osiecki jos...@hybrid.pl napisał(a): Witam, Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? Chodzi o to, by uniemożliwić klientom zaglądanie do katalogów sąsiadów... Na razie mam to rozwiązane tak: - vsftpd, klient po zalogowaniu ma HOME jako / - każdy klient ma HOME w katalogu: /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta, przy czym /home/clients ma usera root.root i 711 Na początek mógłbyś ograniczyć łażenie userom z poziomu php po katalogach (konfiguracja apache peer user) php_admin_value open_basedir /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/public_html:/usr/lib/php:/home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp:/usr/share/pear php_admin_value upload_tmp_dir /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp php_admin_value session.save_path /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp pozdrawiam, Andrzej Augustynowicz ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: pld na hosting PHP - jak rozdzielacie klientów?
On Fri, 12 Dec 2008, Andrzej Augustynowicz wrote: Dnia 2008-12-12, o godz. 10:23:26 Jacek Osiecki jos...@hybrid.pl napisał(a): Czy ktoś przerabiał temat zrobienia bezpiecznego hostingu php? Chodzi o to, by uniemożliwić klientom zaglądanie do katalogów sąsiadów... Na razie mam to rozwiązane tak: - vsftpd, klient po zalogowaniu ma HOME jako / - każdy klient ma HOME w katalogu: /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta, przy czym /home/clients ma usera root.root i 711 Na początek mógłbyś ograniczyć łażenie userom z poziomu php po katalogach (konfiguracja apache peer user) php_admin_value open_basedir /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/public_html:/usr/lib/php:/home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp:/usr/share/pear O, właśnie - o tym zapomniałem. php_admin_value upload_tmp_dir /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp php_admin_value session.save_path /home/clients/4c4712a4141d261ec0ca8f9037950685/nazwaklienta/tmp A to faktycznie też się przyda - a na pewno nie zaszkodzi :) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 To nie logika, to polityka (c) Kabaret pod Wyrwigroszem 2006___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
