Jak skonfigurować uprawnienia Linuksa do folderu WWW?

69

Zaktualizowano podsumowanie

Katalog / var / www jest własnością, root:rootco oznacza, że ​​nikt nie może go używać i jest całkowicie bezużyteczny. Ponieważ wszyscy chcemy, aby serwer WWW faktycznie działał (i nikt nie powinien logować się jako „root”), musimy to naprawić.

Tylko dwa podmioty potrzebują dostępu.

  1. PHP / Perl / Ruby / Python potrzebują dostępu do folderów i plików, ponieważ tworzą wiele z nich (tj /uploads/.). Te języki skryptowe powinny działać pod nginx lub apache (lub nawet innymi rzeczami, takimi jak FastCGI dla PHP).

  2. Deweloperzy

Jak uzyskują dostęp? Wiem, że ktoś już to kiedyś robił. Przy tak wielu miliardach stron internetowych można by pomyśleć, że będzie więcej informacji na ten temat.


Wiem, że 777 to pełne uprawnienie do odczytu / zapisu / wykonania dla właściciela / grupy / innej osoby. Nie wydaje się to konieczne, ponieważ daje losowym użytkownikom pełne uprawnienia.

Z jakich uprawnień należy korzystać /var/www, aby:

  1. Kontrola źródła, taka jak git lub svn
  2. Użytkownicy w grupie takiej jak „strony internetowe” ( lub nawet dodani do „danych www” )
  3. Serwery takie jak apache lub lighthttpd
  4. I PHP / Perl / Ruby

czy wszyscy mogą tam czytać, tworzyć i uruchamiać pliki (i katalogi)?

Jeśli mam rację, skrypty Ruby i PHP nie są „wykonywane” bezpośrednio - ale przekazywane do tłumacza. Więc nie ma potrzeby wykonywania uprawnień do plików w /var/www...? Dlatego wydaje się, że prawidłowe zgody byłoby chmod -R 1660co uczyniłoby

  1. wszystkie pliki udostępniane przez te cztery podmioty
  2. wszystkie pliki niewykonalne przez pomyłkę
  3. całkowicie zablokuj wszystkich pozostałych w katalogu
  4. ustaw tryb uprawnień na „lepki” dla wszystkich przyszłych plików

Czy to jest poprawne?

Aktualizacja 1: Właśnie zdałem sobie sprawę, że pliki i katalogi mogą wymagać różnych uprawnień - mówiłem o plikach powyżej, więc nie jestem pewien, jakie powinny być uprawnienia do katalogu.

Aktualizacja 2: Struktura folderów /var/wwwzmian drastycznie, ponieważ jeden z czterech powyższych podmiotów zawsze dodaje (a czasem usuwa) foldery i podfoldery o głębokości wielu poziomów. Tworzą również i usuwają pliki, do których inne 3 podmioty mogą potrzebować dostępu do odczytu / zapisu. Dlatego uprawnienia muszą wykonać cztery powyższe czynności zarówno dla plików, jak i katalogów. Ponieważ żaden z nich nie powinien potrzebować pozwolenia na wykonanie (patrz pytanie dotyczące ruby ​​/ php powyżej), zakładam, że rw-rw-r--pozwolenie byłoby wszystkim, co jest potrzebne i całkowicie bezpieczne, ponieważ te cztery podmioty są obsługiwane przez zaufany personel (patrz # 2) i wszystkich innych użytkowników na system ma tylko dostęp do odczytu.

Aktualizacja 3: Dotyczy maszyn do rozwoju osobistego i serwerów prywatnych firm. Brak przypadkowych „klientów internetowych”, takich jak współdzielony host.

Aktualizacja 4: Ten artykuł autorstwa slicehost wydaje się najlepiej wyjaśniać, co jest potrzebne do skonfigurowania uprawnień do folderu www. Jednak nie jestem pewien, jak działa apache / nginx użytkownika lub grupy z PHP LUB svn / git i jak je zmienić.

Aktualizacja 5: W końcu (jak sądzę) znalazłem sposób, aby wszystko to zadziałało (odpowiedź poniżej). Nie wiem jednak, czy jest to właściwy i BEZPIECZNY sposób na zrobienie tego. Dlatego zacząłem nagrodę. Osoba, która ma najlepszą metodę zabezpieczenia katalogu www i zarządzania nim, wygrywa.

Xeoncross
źródło

Odpowiedzi:

47

Po dalszych badaniach wydaje się, że innym (być może lepszym sposobem) odpowiedzią byłoby skonfigurowanie folderu www w ten sposób.

  1. sudo usermod -a -G developer user1 (dodaj każdego użytkownika do grupy programistów)
  2. sudo chgrp -R developer /var/www/site.com/ aby programiści mogli tam pracować
  3. sudo chmod -R 2774 /var/www/site.com/ dzięki czemu tylko programiści mogą tworzyć / edytować pliki (inny / świat może czytać)
  4. sudo chgrp -R www-data /var/www/site.com/uploads dzięki czemu www-data (apache / nginx) może tworzyć przesłane pliki.

Ponieważ gitdziała tak, jak go nazywa użytkownik, to dopóki użytkownik jest w grupie „deweloperów”, powinien móc tworzyć foldery, edytować pliki PHP i zarządzać repozytorium git.

Uwaga: W kroku (3): „2” w 2774 oznacza „ustawić ID grupy” dla katalogu. Powoduje to, że utworzone w nim nowe pliki i podkatalogi dziedziczą identyfikator grupy katalogu nadrzędnego (zamiast podstawowej grupy użytkownika) Odwołanie: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Xeoncross
źródło
Wydaje mi się rozsądny.
wazoox
Dobry. Może jeśli uda mi się to potwierdzić z kilkoma osobami, zastosuję to podejście. To chyba najlepsza odpowiedź, jaką udało mi się wycisnąć z ludzi.
Xeoncross,
Nie określasz, kto byłby właścicielem plików. Czy pozostawiłbyś to jako root? Wtedy tylko sudoers może edytować folder przesyłania (prawdopodobnie nie tak, jak zamierzałeś).
Nic
Tak, root pozostanie właścicielem. Ponieważ jednak właściciel grupy jest teraz „programistą” (i ma uprawnienia do WRX), wszyscy deweloperzy (i Apache / Nginx) również mogą czytać. Nie ma potrzeby sudo.
Xeoncross,
7
Jeszcze jedna rzecz, na którą należy zwrócić uwagę, to umask. Wiele systemów ma domyślną umaskę 022, która usunie uprawnienia do zapisu zarówno dla grupy, jak i publicznego dla nowych plików. Podejrzewam, że chcesz 002 (brak zapisu dla publicznego) lub 007 (brak dostępu dla publicznego). Możesz ustawić umask w konfiguracji Apache i / lub skryptach startowych dla dowolnego procesu, który potrzebuje dostępu do katalogu. Nie zapomnij dodać tego do / etc / profile lub / etc / bashrc, aby był domyślnie ustawiony również dla twoich programistów
Mark Porter
8

Nie jestem pewien, czy to „dobrze”, ale oto, co robię na moim serwerze:

  • / var / www zawiera folder dla każdej witryny.
  • Każda witryna ma wyznaczonego właściciela, który jest ustawiony jako właściciel wszystkich plików i folderów w katalogu witryny.
  • Wszyscy użytkownicy, którzy utrzymują witrynę, są umieszczani w grupie dla witryny.
  • Ta grupa jest ustawiona jako właściciel grupy dla wszystkich plików i folderów w katalogu.
  • Wszelkie pliki lub foldery, które muszą zostać zapisane przez serwer WWW (tj. PHP), mają właściciela zmienionego na www-data, użytkownika, pod którym działa apache.

Należy pamiętać, że należy włączyć bit wykonywania w katalogach, aby można było wyświetlić zawartość.

Nic
źródło
W jaki sposób git / svn lub PHP tworzą nowe foldery?
Xeoncross,
2
PHP działa w tym samym kontekście użytkownika co serwer WWW, dzięki czemu może tworzyć pliki i foldery w dowolnym katalogu będącym własnością serwera. Na ogół jest tylko kilka takich folderów (na przykład / uploads /). Nie jestem pewien co do git / svn - czy możesz dodać je do konta grupy, które kontroluje witrynę?
Nic
najwyraźniej git działa tak, jak uruchamiający go użytkownik - tak jak każde inne narzędzie.
Xeoncross
Następnie dodaj użytkownika git do grupy apache i nadaj grupie uprawnienia do zapisu.
David Rickman
Powiedziałem właśnie, że git nie ma użytkownika - działa jak bieżący użytkownik, który go używa.
Xeoncross,
7

Po przeprowadzeniu dalszych badań wydaje się, że NARZĘDZIA git / svn NIE stanowią problemu, ponieważ działają tak, jak używa tego użytkownik. (Jednak demony git / svn to inna sprawa!) Wszystko, co stworzyłem / sklonowałem za pomocą git, miało moje uprawnienia, a narzędzie git zostało wymienione, w /usr/binktórym pasuje ta teza.

Uprawnienia Git rozwiązane.

Wydaje się, że uprawnienia użytkownika można rozwiązać, dodając wszystkich użytkowników potrzebujących dostępu do katalogu www do www-datagrupy, w której działają apache (i nginx).

Wygląda więc na to, że jedna odpowiedź na to pytanie brzmi następująco:

Domyślnie /var/wwwjest własnością root:rooti nikt nie może dodawać ani zmieniać tam plików.

1) Zmień właściciela grupy

Najpierw musimy zmienić grupę katalogów www, która będzie własnością „www-data” zamiast grupy „root”

sudo chgrp -R www-data /var/www

2) Dodaj użytkowników do danych www

Następnie musimy dodać bieżącego użytkownika (i każdego innego) do grupy danych www

sudo usermod -a -G www-data demousername

3) Katalog www CHMOD

Zmień uprawnienia, aby TYLKO właściciel (root) i wszyscy użytkownicy w grupie „www-data” mogli rwx (odczyt / zapis / wykonywanie) plików i katalogów ( nikt inny nie powinien mieć do nich dostępu ).

sudo chmod -R 2770 /var/www

Teraz wszystkie pliki i katalogi utworzone przez dowolnego użytkownika, który ma dostęp (tj. W grupie „www-data”) będą dostępne do odczytu / zapisu przez apache, a więc php.

Czy to jest poprawne? Co z plikami tworzonymi przez PHP / Ruby - czy użytkownicy danych www mogą uzyskać do nich dostęp?

Xeoncross
źródło
6
Nie podoba mi się pomysł zapisywania wszystkich plików internetowych przez PHP, ponieważ zwiększa to twoją możliwą ekspozycję, jeśli istnieje luka w skrypcie.
Nic
Ok, cóż, wiem, że używam PHP do tworzenia wielu plików tekstowych, plików tar, logów i obrazów (plus foldery), więc po prostu zakładałem, że wszystko powinno być możliwe do zapisania. Być może jednak Twoje prawo i PHP powinny być w stanie ZMIENIĆ PLIKI, KTÓRE TWORZĄ, co byłoby nieszkodliwe, ponieważ 99% wszystkich aplikacji PHP nigdy nie tworzy plików skryptów. Innym wyborem wydaje się być zezwolenie tylko niektórym katalogom na dostęp do zapisu w PHP (/ uploads /), co nie powoduje, ponieważ wtedy PHP może nadal zostać użyte do stworzenia czegoś złego. Jakieś pomysły?
Xeoncross
2
Staraj się trzymać skrypt i dane osobno. Nawet jeśli atakującemu uda się upuścić coś do / uploads /, nie powinno to być wykonalne. Bezpieczeństwo w warstwach jest kluczowe.
Nic
6

Lepkość nie jest dziedziczeniem uprawnień. Lepkość katalogu oznacza, że ​​tylko właściciel pliku lub właściciel katalogu może zmienić nazwę lub usunąć ten plik w katalogu, pomimo uprawnień odmiennych. Tak więc 1777 na / tmp /.

W klasycznym Uniksie nie ma dziedziczenia uprawnień na podstawie systemu plików, tylko na podstawie umask bieżącego procesu. W * BSD lub Linux z setgid w katalogu pole grupy nowo utworzonych plików będzie ustawione tak samo jak pole katalogu nadrzędnego. Aby uzyskać cokolwiek więcej, musisz zajrzeć do list ACL, z „domyślną” listą ACL dla katalogów, które pozwalają odziedziczyć uprawnienia.

Powinieneś zacząć od zdefiniowania: * jakie użytkownicy mają dostęp do systemu * jaki jest twój model zagrożenia

Na przykład, jeśli prowadzisz hosting z wieloma klientami i nie chcesz, aby widzieli się nawzajem plików, możesz użyć wspólnej grupy „webcusts” dla wszystkich tych użytkowników i trybu katalogu 0705. Następnie pliki są obsługiwane przez proces serwera WWW ( nie w „webcusts”) zobaczy Inne perms i będzie dozwolony; klienci nie widzą się nawzajem, a użytkownicy mogą zadzierać z własnymi plikami. Oznacza to jednak, że w momencie, gdy zezwolisz na CGI lub PHP, musisz upewnić się, że procesy działają jako konkretny użytkownik (dobra praktyka i tak, dla wielu użytkowników na jednym hoście, dla odpowiedzialności). W przeciwnym razie klienci mogą zepsuć się nawzajem plikami, korzystając z interfejsu CGI.

Jeśli jednak użytkownik wykonujący witrynę internetową jest taki sam jak jej właściciel, masz problemy z niemożnością ochrony zawartości przed osobami nadużywającymi w przypadku luki w zabezpieczeniach skryptu. Właśnie tam wygrywają dedykowane hosty, dzięki czemu możesz mieć użytkownika wykonawczego innego niż właściciel zawartości statycznej i nie martwić się o interakcje z innymi użytkownikami.

Phil P.
źródło
Dobra odpowiedź. W systemie MacOS X system zachowuje się tak, jakby bit SGID znajdował się automatycznie w katalogach. Lepki bit zazwyczaj oznacza, że ​​możesz usunąć plik tylko wtedy, gdy możesz go zapisać. Oznacza to, że każdy może usunąć publicznie zapisywalny plik w / tmp. W MacOS X / tmp jest dowiązaniem symbolicznym do prywatnego katalogu dla użytkownika - więc w końcu nie ma możliwości udostępniania.
Jonathan Leffler
Dzięki za odpowiedź, zaktualizowałem pytanie o więcej informacji.
Xeoncross,
Jonathan: lepki bit oznacza tylko właściciela katalogu lub właściciela pliku, może zmienić nazwę lub usunąć go (tj. Działać po jego wpisie w katalogu „plik”). Uprawnienia do poszczególnych plików nie są odtwarzane w przypadku tych operacji na katalogach ( rename(), unlink()), a jedynie działań na samym pliku ( open()). To jest „zwykłe” zachowanie.
Phil P
2

Uważam, że najlepszym sposobem na to jest użycie list ACL Posix. Są wygodne w obsłudze i oferują wszystkie potrzebne funkcje.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

Tie-fighter
źródło
+1 za pomocne informacje na temat list ACL. Nie chcę jednak, aby dodatkowe śmieci blokowały system tylko w celu zarządzania prostym serwerem z kilkoma programistami. Nie czuję się też komfortowo przy ponownej kompilacji jądra w celu korzystania z list ACL.
Xeoncross,
@Xeoncross: Listy ACL niczego nie zabijają. Są to po prostu metainformacje, takie jak normalne uprawnienia do plików. Nie jest to wcale takie „dodatkowe” i skomplikowane, uważam, że jest to najprostszy i najlepszy sposób zarządzania uprawnieniami, a nie jakieś mylące rozwiązanie typu sticky / group / cokolwiek innego. Nie bój się, po prostu ponownie włóż acl i spróbuj!
Tie-fighter
1

Właścicielem pliku powinna być osoba, która go utworzy, a grupą powinny być dane www. Tryb dla katalogów / plików to wtedy ogólnie 755/644. Podczas gdy dla katalogów i plików grupa potrzebuje dostępu do zapisu, mod to 775/664. Załóżmy, że paddy jest deweloperem. W sumie powoduje to:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;
Jonny
źródło
0

Dodając do odpowiedzi @ Xeoncross, myślę, że dobrze byłoby osobno skonfigurować uprawnienia do plików i katalogów.

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

Umożliwi to programistom tworzenie i modyfikowanie katalogów w katalogu / var / www. Co wydaje się ważne, ponieważ programiści mogą potrzebować utworzyć dodatkowe katalogi lub usunąć katalog, który nie jest już potrzebny.

Umożliwi to także programistom tworzenie i modyfikowanie plików kodu (odczytywanie plików HTML, PHP itp.) Ale nadal pozwoli wszystkim dostęp tylko do odczytu.

MikeyE
źródło