Wypowiedzi
-
No dobra z tą blokadą katalogu /home to miałeś rację ;)
Ustawiłem uprawnienia do katalogów w taki sposób:
/home - 711
/home/* - 710
I wszystko działa jak należy:) Myślałem, że będzie trzeba więcej kombinować. -
Stanisław P.:
Michał Korus:
To jest złe podejście - teoretycznie uniemożliwia użytkownikom dostęp do katalogów domowych przez ssh... /home powinien być przeglądalny. To katalogi /home/* powinny mieć uprawnienia 0700, żeby różni userzy nie mogli się nawzajem oglądać.
I teraz wrzucając chmod 700 na katalog /home blokuje możliwość podglądnięcia nazw katalogów (co na niewiele się zda kiedy na się dostęp do /etc/passwd).
Nieprawda. Ustawiłem chmod na 700 i mogę bez problemu logować się przez SSH (inaczej zablokowałbym sobie serwer). Podglądając inny hosting ustawiłem katalogi /home/* na 711, ale nadal nic to nie daje. Wystarczy, że zrobie:
cd /home/inny_user/
Permission denied [ OK ]
cd /home/inny_user/htdocs
ls -la
Wchodzi bez problemu
Mogę co prawda wrzucić chmod 700 na wszystkie pliki i katalogi w folderze /home, ale znowu zacznie krzyczeć vsftpd, że nie może się dostać do danego katalogu.
Z jakimi uprawnieniami chodzi vsftpd? Nie znam jego architektury, ale spodziewam się, że będzie działał jako root i wtedy będzie miał i tak dostęp, albo będzie się setuid'ował na użytkownika i też będzie miał tam dostęp... Jak to u Ciebie wygląda?
Wchodzi z poziomu użytkownika. Problem w tym że jak ustawiłem chmod 700 to wywalało mi w kliencie FTP błąd wewnętrzny. Z 711 działa bez problemu
W takim razie pomyślałem czy by nie skorzystać z openbase_dir wbudowanego w PHP i ograniczającego dostęp do wybranych katalogów. Niestety i tym razem nie było to dobre rozwiązanie bo openbase_dir gryzie się z curlem: http://www.web-development-blog.com/archives/curl-foll... . Jak widać można naprawić ten problem, ale nie będę miał nic go gadania jeśli skrypt zostanie zaszyfrowany (Ioncube).
Nie możesz powiedzieć userom, że to nowa zasada i follow jest dostępny tylko w katalogach X i Y? Daj im miesiąc na przetrawienie tematu, a później wszyscy mają się dostosować np.
Niestety jednym z użytkowników jestem ja sam więc odpada takie rozwiązanie. Z tego co widziałem w Plesku jest to rozwiązane tak, że jeśli Apache (ja mam Nginxa) korzysta z mod_php to automatycznie jest wstawiane ograniczenie openbase_dir. Jeśli zaś korzysta z fastcgi takie ograniczenie nie występuje
Kolejna sprawa co z SSH. Niektórym użytkownikom chciałbym dać możliwość logowania się do shella np żeby rozpakowali przesłany plik. Jailkit (chroot) potrafi rozwiązać ten problem, ale z kolei replikuje binarki i trudno by było je później aktualizować (np jakby pojawiła się jakaś krytyczna luka w programie). Druga sprawa, że katalog domowy takie użytkownika wyglądałby jak istny śmietnik.
W jakim celu dajesz im dostęp? Tzn. co to za użytkownicy? Jeśli to nie jest jakieś wielce restrykcyjne środowisko pozwól im robić co chcą. Jak coś zepsują to niech odtwarzają z backupów (robisz je, prawda?) albo przez support...
Użytkownicy zepsują swoje środowisko w jakimś momencie tak czy tak - nie obronisz się przed tym.
Backupy robię, w zasadzie nie ja ale robią się automatycznie. A w jakim celu ? Niektórzy (np ja ;)) chcą mieć repozytorium gita na serwerze
Co do openvz to nie rozumiem do końca jak go używasz... Spodziewałbym się, że jeśli dajesz userom pseudo-wirtualki to zarządzają nimi jak chcą. Ale widzę, że to jedna maszyna i użytkownicy są lokalni - więc do czego tego VZ'a używasz?
Nie zrozumiałeś. Ja sam mam taką pseudo-wirtualkę. Nie mam prawdziwego serwera tylko VPS'a postawionego na openvz -
No dobra, wytłumaczę mój problem jeszcze raz. Mam zainstalowany serwer Nginx, który pełni rolę proxy dla Javy (poprzez AJB komunikuje się z Tomcatem 7) oraz PHP (przez fastcgi - procesy uruchamiają się z uprawnieniami użytkownika). Wszystko pięknie działa tylko mam problem z odpowiednimi uprawnieniami dla katalogów domowych (/home) gdzie znajdują się skrypty php. Mniej więcej wygląda to tak:
---home
------user1
---------htdocs
------------index.php
------------config.xml
------user2
---------htdocs
------------index.php
I teraz wrzucając chmod 700 na katalog /home blokuje możliwość podglądnięcia nazw katalogów (co na niewiele się zda kiedy na się dostęp do /etc/passwd). Mogę co prawda wrzucić chmod 700 na wszystkie pliki i katalogi w folderze /home, ale znowu zacznie krzyczeć vsftpd, że nie może się dostać do danego katalogu. Kolejna sprawa co z plikami przesyłanymi przez samego użytkownika (przez FTP) ? Mogę nadać odpowiednią maskę w ustawieniach vsftpd, ale znowu to nic nie da jeśli użytkownik będzie miał możliwość zmiany uprawnień (czyt. nieumyślnie zmniejszy bezpieczeństwo). W takim razie pomyślałem czy by nie skorzystać z openbase_dir wbudowanego w PHP i ograniczającego dostęp do wybranych katalogów. Niestety i tym razem nie było to dobre rozwiązanie bo openbase_dir gryzie się z curlem: http://www.web-development-blog.com/archives/curl-foll... . Jak widać można naprawić ten problem, ale nie będę miał nic go gadania jeśli skrypt zostanie zaszyfrowany (Ioncube).
Kolejna sprawa co z SSH. Niektórym użytkownikom chciałbym dać możliwość logowania się do shella np żeby rozpakowali przesłany plik. Jailkit (chroot) potrafi rozwiązać ten problem, ale z kolei replikuje binarki i trudno by było je później aktualizować (np jakby pojawiła się jakaś krytyczna luka w programie). Druga sprawa, że katalog domowy takie użytkownika wyglądałby jak istny śmietnik.
Jeśli zaś chodzi o samą Jave to miałem na myśli Tomcata 7. Nie chce go jakoś specjalnie ograniczać. Chce tylko zablokować mu możliwość podglądnięcia plików z katalogów domowych (/home).
Na koniec dodam jeszcze, że wszyscy użytkownicy, który posiadają skrypty PHP w katalogu domowym (mają własne strony) należą do grupy www-data. Nie szukam jakiś skomplikowanych rozwiązań bo nie wiem czy podoła temu Openvz. Miałem już z nim problemy przy konfiguracji firewalla (iptables), a jeszcze nie do końca działa na nim quota. Jednym słowem mam z nim same problemy, a dopiero się uczę -
Witam,
Chciałbym się zapytać jak skutecznie zabezpieczyć katalogi domowe tak, aby inni użytkownicy nie mieli dostępu do poufnych plików/katalogów. Nadanie chmodu 700 katalogom /home, /etc/nginx/sites-available oraz /etc/nginx/sites-enabled nieco zwiększa bezpieczeństwo, ale nadal istnieje możliwość "wejścia" do katalogu innego użytkownika (np jeśli znamy nazwę użytkownika lub domenę). Próbowałem bawić się Jailkit'em i nawet udało mi się uruchomić skrypty php w piaskownicy (w trybie fastcgi) lecz praktycznie wszystkie rozszerzenia (do php) przestały działać. W dodatku jailkit (chroot) praktycznie wszystko powielał i byłyby problem z aktualizacją.
Potem przypomniałem sobie o opcji open_basedir w php.ini która ogranicza "surfowanie" po katalogach jednak i ona z kolei nie była dobrym rozwiązaniem bo raz że działała w samym PHP (a potrzebuje też rozwiązania dla SSH i Javy) to dwa są problemy z curlem (które można rozwiązać, ale nie będę sam modyfikował każdego skryptu).
Na koniec dodam, że korzystam z Ubuntu Server 10.04 zainstalowanym na maszynie wirtualnej OpenVZ (wiem zły wybór:/).
Czekam na jakomkolwiek pomoc i pozdrawiam:) -
APC wiadomo podstawa. Już na samym początku go zainstalowałem;)
Mam nieco problemów z konfiguracją suPHP. Nie widzieć czemu przy restarcie apacha wywala mi "Invalid command 'suPHP_UserGroup'...", a wszystko robiłem wg tego tutoriala: http://www.lecaptain.org/tech/suphp-on-plesk-with-cent...
EDIT: W wersji 0.7 usunęli chyba ta komendę i zrobili tak że automatycznie odczytywane są uprawnienia pliku i uruchomiane pod danym użytkownikiem. Poza tym wszystkie pliki muszą mieć uprawnienia nie mniejsze/nie większe niż 644. Niestety suPHP okazał się bardzo wolny:/ Na szczęście istnieje jeszcze coś takiego jak suExec, który w połączeniu z modem fastcgi tworzy zgrany duet. Jak się okazało Plesk od samego początku miał wbudowany ten moduł w opcjach i wystarczyło go po prostu włączyć dla konkretnej domeny. Jak zwykle szukałem daleko, a rozwiązanie było tak blisko:/ Jakby ktoś pytał to open_basedir jest domyślne wyłączony jeśli korzystamy z modułu fastcgi. Procesy PHP uruchamiane są na uprawnieniach użytkownika (suExec) więc nie ma potrzeby korzystania z open_basedirMichał Korus edytował(a) ten post dnia 04.07.10 o godzinie 01:33 -
Dzięki, jednak nie do końca udało mi się rozwiązać problem. Ustawiłem uprawnienia 711 na katalogu /var/www/vhosts i już się nie listują pliki i katalogi (wykorzystuje skrypt php) jednak nadal jest dostęp do podkatalogów całość wygląda tak:
--vhost drwx--x--x root root
----domain.com drwx--x--x root root
-------httpdocs drwxr-x--- user psaserv
----domain2.com drwx--x--x root root
-------httpdocs drwxr-x--- user2 psaserv
Oczywiście pominąłem mniej ważne katalogi.
EDIT:
Doszłem do tego że trzeba uaktywnić suPHP tylko że jest on około 30% wolniejszy od mod_phpMichał Korus edytował(a) ten post dnia 02.07.10 o godzinie 17:03 -
Witam,
Mam mały problem z konfiguracją Pleska. W jaki sposób zabezpieczyć katalogi użytkowników (/var/www/vhosts/*), aby użytkownicy z wyłączonym open_basedir (PHP) nie mieli dostępu do katalogów pozostałych użytkowników ? Obecnie jest tak, że użytkownicy mają dostęp tylko do katalogów /var/www/vhost/[ USER ]/httpdocs oraz /var/www/vhost/[ USER ]/httpsdocs. Niestety przy włączonym open_basedir rozszerzenie curl wariuje:/ Co prawda znalazłem obejście tego problemu: http://www.edmondscommerce.co.uk/curl/php-curl-curlopt... ale niestety nic nie poradzę jeśli skrypt użytkownika jest zakodowany przy pomocy ionCube. Proszę o jakąkolwiek pomoc...