Podejmując decyzję, jakich uprawnień użyć, musisz dokładnie wiedzieć, kim są Twoi użytkownicy i czego potrzebują. Serwer WWW współdziała z dwoma typami użytkowników.
Uwierzytelnieni użytkownicy mają konto użytkownika na serwerze i mogą mieć określone uprawnienia. Zwykle obejmuje to administratorów systemu, programistów i konta usług. Zwykle wprowadzają zmiany w systemie za pomocą SSH lub SFTP.
Anonimowi użytkownicy są użytkownikami Twojej witryny. Chociaż nie mają uprawnień do bezpośredniego dostępu do plików, mogą poprosić o stronę internetową, a serwer internetowy działa w ich imieniu. Możesz ograniczyć dostęp anonimowych użytkowników, uważając na to, jakie uprawnienia ma proces serwera WWW. W wielu dystrybucjach Linuksa Apache działa jako www-dataużytkownik, ale może być inny. Użyj ps aux | grep httpdlub, ps aux | grep apacheaby zobaczyć, jakiego użytkownika Apache używa w twoim systemie.
Uwagi na temat uprawnień do Linuksa
Linux i inne systemy zgodne z POSIX używają tradycyjnych uprawnień uniksowych. W Wikipedii znajduje się doskonały artykuł na temat uprawnień do systemu plików, więc nie powtórzę tutaj wszystkiego. Ale jest kilka rzeczy, o których powinieneś wiedzieć.
Skrypty bitowe zinterpretowane (np. Ruby, PHP) działają dobrze bez uprawnień do wykonywania. Tylko pliki binarne i skrypty powłoki wymagają bitu wykonania. Aby przejść (wejść) do katalogu, musisz mieć uprawnienia do wykonywania tego katalogu. Serwer sieciowy potrzebuje tego uprawnienia, aby wyświetlić katalog lub udostępnić zawarte w nim pliki.
Domyślne nowe uprawnienia do pliku
Po utworzeniu plik zwykle dziedziczy identyfikator grupy tego, kto go utworzył. Ale czasami chcesz, aby nowe pliki dziedziczyły identyfikator grupy folderu, w którym zostały utworzone, więc włączasz bit SGID w folderze nadrzędnym.
Domyślne wartości uprawnień zależą od twojego umask. Umask odejmuje uprawnienia od nowo tworzonych plików, więc wspólna wartość 022 powoduje, że pliki są tworzone za pomocą 755. Podczas współpracy z grupą warto zmienić umask na 002, aby tworzone przez Ciebie pliki mogły być modyfikowane przez członków grupy. A jeśli chcesz dostosować uprawnienia przesyłanych plików, musisz zmienić umask na apache lub uruchomić chmod po przesłaniu pliku.
Problem z 777
Kiedy chmod 777twoja strona internetowa nie ma żadnych zabezpieczeń. Każdy użytkownik w systemie może zmienić lub usunąć dowolny plik w witrynie. Ale co ważniejsze, pamiętaj, że serwer internetowy działa w imieniu odwiedzających twoją stronę, a teraz serwer internetowy może zmieniać te same pliki, które wykonuje. Jeśli w Twojej witrynie występują luki w programowaniu, można je wykorzystać do zniszczenia witryny, włożenia ataków phishingowych lub kradzieży informacji z serwera bez Twojej wiedzy.
Dodatkowo, jeśli twój serwer działa na dobrze znanym porcie (który powinien uniemożliwić użytkownikom innym niż root odradzanie się usług odsłuchowych, które są dostępne na całym świecie), oznacza to, że twój serwer musi być uruchomiony przez root (chociaż każdy rozsądny serwer natychmiast spadnie na konto mniej uprzywilejowane, gdy port zostanie powiązany). Innymi słowy, jeśli prowadzisz serwer WWW, na którym główny plik wykonywalny jest częścią kontroli wersji (np. Aplikacja CGI), pozostawiając jego uprawnienia (lub, w tym przypadku, uprawnienia do katalogu zawierającego, ponieważ użytkownik może zmienić nazwę plik wykonywalny) w 777 pozwala każdemu użytkownikowi uruchomić dowolny plik wykonywalny jako root.
Zdefiniuj wymagania
- Programiści potrzebują dostępu do odczytu / zapisu plików, aby mogli aktualizować witrynę
- Programiści potrzebują odczytu / zapisu / wykonania w katalogach, aby mogli przeglądać
- Apache potrzebuje dostępu do odczytu plików i interpretowanych skryptów
- Apache potrzebuje dostępu do odczytu / wykonywania do katalogów obsługiwanych
- Apache potrzebuje dostępu do odczytu / zapisu / wykonania do katalogów w celu przesłania treści
Obsługiwany przez jednego użytkownika
Jeśli tylko jeden użytkownik jest odpowiedzialny za utrzymanie witryny, ustaw go jako właściciela w katalogu witryny i nadaj mu pełne uprawnienia rwx. Apache nadal potrzebuje dostępu, aby mógł obsługiwać pliki, więc ustaw www-data jako właściciela grupy i daj grupie uprawnienia rx.
W twoim przypadku Ewa, której nazwa użytkownika może być eve, jest jedynym użytkownikiem, który utrzymuje contoso.com:
chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve www-data 4096 Feb 5 22:52 contoso.com
Jeśli masz foldery, które Apache musi zapisywać, możesz po prostu zmodyfikować wartości uprawnień właściciela grupy, aby www-data miał dostęp do zapisu.
chmod g+w uploads
ls -l
drwxrws--- 2 eve www-data 4096 Feb 5 22:52 uploads
Zaletą tej konfiguracji jest to, że staje się trudniejsze (ale nie niemożliwe *) dla innych użytkowników w systemie do węszenia, ponieważ tylko użytkownicy i właściciele grup mogą przeglądać katalog Twojej witryny. Jest to przydatne, jeśli masz tajne dane w swoich plikach konfiguracyjnych. Uważaj na swój umask! Jeśli utworzysz tutaj nowy plik, wartości uprawnień prawdopodobnie będą miały domyślną wartość 755. Możesz uruchomić umask 027, aby nowe pliki miały domyślną wartość 640 ( rw- r-- ---).
Obsługiwana przez grupę użytkowników
Jeśli za utrzymanie witryny odpowiada więcej niż jeden użytkownik, musisz utworzyć grupę, która będzie używana do przypisywania uprawnień. Dobrą praktyką jest utworzenie osobnej grupy dla każdej witryny i nadanie jej nazwy po tej stronie.
groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob
W poprzednim przykładzie użyliśmy właściciela grupy, aby nadać uprawnienia Apache, ale teraz jest to używane dla grupy programistów. Ponieważ właściciel użytkownika nie jest już dla nas przydatny, ustawienie go jako root jest prostym sposobem na zapewnienie, że żadne uprawnienia nie zostaną ujawnione. Apache nadal potrzebuje dostępu, więc dajemy dostęp do odczytu reszcie świata.
chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Jeśli masz foldery, które Apache może zapisywać, możesz ustawić Apache jako właściciela lub właściciela grupy. Tak czy inaczej, będzie miał dostęp do wszystkich potrzebnych danych. Osobiście wolę uczynić go właścicielem użytkownika, aby programiści mogli nadal przeglądać i modyfikować zawartość folderów przesyłania.
chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data dev-fabrikam 4096 Feb 5 22:52 uploads
Chociaż jest to powszechne podejście, ma jednak pewną wadę. Ponieważ każdy inny użytkownik w systemie ma takie same uprawnienia do witryny, jak Apache, inni użytkownicy mogą łatwo przeglądać witrynę i czytać pliki, które mogą zawierać tajne dane, takie jak pliki konfiguracyjne.
Możesz mieć swoje ciasto i zjeść je
Można to później ulepszyć. Jest całkowicie legalne, że właściciel ma mniej uprawnień niż grupa, więc zamiast marnować właściciela użytkownika, przypisując go do konta root, możemy uczynić Apache właścicielem użytkownika w katalogach i plikach na twojej stronie. Jest to odwrócenie scenariusza pojedynczego opiekuna, ale działa równie dobrze.
chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Jeśli masz foldery, które Apache musi zapisywać, możesz po prostu zmodyfikować wartości uprawnień dla właściciela użytkownika, aby www-data miał dostęp do zapisu.
chmod u+w uploads
ls -l
drwxrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Jedną z rzeczy, na które należy uważać przy tym rozwiązaniu, jest to, że użytkownik nowych plików będzie pasował do twórcy, zamiast być ustawiony na www-data. Dlatego wszelkie nowe pliki, które utworzysz, nie będą czytelne dla Apache, dopóki ich nie przejrzysz.
* Separacja uprawnień Apache
Wspomniałem wcześniej, że inni użytkownicy mogą węszyć w Twojej witrynie bez względu na to, jakiego rodzaju uprawnień używasz. Domyślnie wszystkie procesy Apache działają jako ten sam użytkownik danych www, więc każdy proces Apache może odczytywać pliki ze wszystkich innych stron internetowych skonfigurowanych na tym samym serwerze, a czasem nawet dokonywać zmian. Każdy użytkownik, który może zmusić Apache do uruchomienia skryptu, może uzyskać taki sam dostęp, jak sam Apache.
Aby zwalczyć ten problem, istnieją różne podejścia do rozdzielania uprawnień w Apache. Jednak każde podejście ma różne wady wydajności i bezpieczeństwa. Moim zdaniem każda witryna o wyższych wymaganiach bezpieczeństwa powinna być uruchomiona na serwerze dedykowanym zamiast używać VirtualHosts na serwerze współdzielonym.
Dodatkowe uwagi
Nie wspominałem o tym wcześniej, ale zwykle jest to zła praktyka, gdy programiści edytują stronę bezpośrednio. W przypadku większych witryn znacznie lepiej jest mieć system wydań, który aktualizuje serwer WWW z zawartości systemu kontroli wersji. Podejście jednego opiekuna jest prawdopodobnie idealne, ale zamiast osoby masz zautomatyzowane oprogramowanie.
Jeśli Twoja witryna zezwala na przesyłanie plików, które nie muszą być obsługiwane, pliki te powinny być przechowywane gdzieś poza katalogiem głównym. W przeciwnym razie może się okazać, że ludzie pobierają pliki, które miały być tajne. Na przykład, jeśli pozwalasz uczniom na przesyłanie zadań, należy je zapisać w katalogu, który nie jest obsługiwany przez Apache. Jest to również dobre podejście do plików konfiguracyjnych zawierających sekrety.
W przypadku witryny o bardziej złożonych wymaganiach warto zapoznać się z listami kontroli dostępu . Umożliwiają one znacznie bardziej zaawansowaną kontrolę uprawnień.
Jeśli Twoja witryna ma złożone wymagania, możesz napisać skrypt, który konfiguruje wszystkie uprawnienia. Przetestuj to dokładnie, a następnie zachowaj bezpieczeństwo. Może być na wagę złota, jeśli z jakiegoś powodu będziesz musiał odbudować swoją stronę.