Jakie są idealne uprawnienia uniksowe dla zwykłych katalogów projektów WWW?

Jakie są idealne minimalne uprawnienia w formacie ósemkowym dla następujących w napisanej aplikacji internetowej?

1. Katalog, w którym będą znajdować się przesłane przez użytkownika pliki statyczne (pliki images / swf / js)
2. Katalog, w którym rezydują przesłane przez administratora pliki statyczne (pliki images / swf / js)
3. Katalog, w którym znajdują się biblioteki używane w aplikacji
4. Katalog, w którym będą się znajdować skrypty wykonawcze / przeglądalne po stronie serwera
5. Katalog, w którym już istniejące pliki (txt lub xml) będą edytowane kodem po stronie serwera

Oto moje sugestie i uzasadnienia

1. 555, każdy może czytać i pisać, nikt nie może wykonać
2. 544, sam właściciel może pisać, wszyscy inni mogą tylko czytać, nikt nie może wykonać
3. 000, nikt nie musi czytać, pisać ani uruchamiać, będzie używany tylko przez serwer WWW?
4. 661, właściciel może czytać, pisać, wszyscy inni mogą tylko wykonywać
5. 600, właściciel może czytać, pisać (może nie być potrzebny), nikt inny nie może nic zrobić

Teraz interesują mnie dwie rzeczy:

1. Czy w aplikacjach internetowych jest coś, czego nie zauważyłem na pierwszej liście?
2. Czy jest coś, z czym się nie zgadzasz na drugiej liście, jaka jest twoja alternatywa i dlaczego jest lepsza?

Zakładając, że „aplikacja internetowa” działa na serwerze (np. Apache, Nginx itp.) I jest napisana w dynamicznym języku skryptowym (np. PHP, Ruby itp.), Masz nieporozumienie, kim jest „użytkownik”.

Użytkownik nie jest osobą zalogowaną do Twojej aplikacji, a jego rola w aplikacji (admin itp.) Jest całkowicie nieistotna dla scenariusza. Użytkownik jest użytkownikiem systemu Linux, na którym działa proces. Kod Twojej witryny jest uruchamiany tylko jako jeden użytkownik - może to być użytkownik twojego serwera (co nie jest tak naprawdę dobrą rzeczą), lub może to być użytkownik specyficzny dla Twojej witryny (co jest znacznie lepsze).

W systemie Linux użytkownicy należą do grup - możemy dodać użytkownika do innej grupy i przypisać uprawnienia do tej grupy.

Dobra konfiguracja sprawi, że Twój serwer będzie działał jako jeden użytkownik (nazwijmy tego użytkownika „serwerem WWW”), a Twój dynamiczny język skryptowy (np. Przez FastCGI) jako własny użytkownik (jeden użytkownik na witrynę - nazwijmy naszego pierwszego użytkownika „witryną 1”) .

Aby serwować twoje pliki, serwer musi mieć do nich dostęp, a język skryptowy potrzebuje do nich dostępu. Oznacza to, że „site1” i „webserver” muszą być w stanie odczytać twoje pliki. Jednak tylko jeden z nich może „posiadać” pliki. Właściciel jest „użytkownikiem” (w użytkowniku, grupie, innym). Potrzebujemy również naszego języka skryptowego, aby móc pisać do katalogu (i czytać zapisane przez niego pliki). Użytkownik „site1” potrzebuje zatem uprawnień do odczytu i zapisu. Ponieważ chcemy, aby uprawnienia grupowe i inne były jak najbardziej restrykcyjne, naszym „właścicielem” będzie „witryna1”, a odpowiednie uprawnienia użytkownika będą odczytywane i zapisywane.

Ponieważ nie możemy określić uprawnień dla naszego serwera jako innego „użytkownika”, dodamy „serwer” do grupy „witryna1” (możesz oczywiście utworzyć inną grupę z „witryną 1” i „serwerem”). członkowie tej grupy otrzymają takie same uprawnienia. Najbardziej luźne uprawnienia (użytkownika, grupy, innego zestawu) zostaną zastosowane do dowolnego użytkownika w celu ustalenia jego uprawnień.

Warto zauważyć, że dobra konfiguracja nie powinna wymagać od plików uprawnień do wykonywania dla języka dynamicznego. Pliki nie są uruchamiane bezpośrednio, ale są wczytywane do interpretera - do uruchomienia typowego skryptu potrzebne są tylko uprawnienia do odczytu (takie, które nic nie piszą).

„Wykonaj” uprawnienie do katalogów ma inne znaczenie - umożliwia przechodzenie bez możliwości czytania zawartości. Aby móc odczytać plik w katalogu, użytkownik musi mieć uprawnienia do „wykonywania” KAŻDEGO katalogu nad nim.

W przypadku aplikacji internetowej każdy plik musi mieć uprawnienia odczytu od właściciela - w przeciwnym razie jest to dość bezcelowy plik. Niezależnie od tego, czy użytkownik lub administrator przesyła pliki (za pośrednictwem aplikacji internetowej), „właściciel” (tj. Język dynamiczny) potrzebuje uprawnień do zapisu. Wydajna konfiguracja będzie próbowała obsługiwać pliki statyczne bezpośrednio przez serwer WWW, ponieważ języki dynamiczne mają tendencję do powolnego czytania dużych plików i echa zawartości. Serwer sieciowy potrzebuje zatem dostępu do odczytu plików statycznych.

Dlatego minimalnymi uprawnieniami do plików mogą być:

• Plik w katalogu, w którym znajdują się pliki statyczne przesłane przez użytkownika (pliki images / swf / js): 640
• Plik w katalogu, w którym administrator przesłał pliki statyczne (pliki images / swf / js): 640
• Plik w katalogu, w którym znajdują się biblioteki używane w aplikacji: 400 (lub 440)
• Plik w katalogu, w którym będą się znajdować skrypty wykonawcze / przeglądalne po stronie serwera: 400 (lub 440)
• Plik w katalogu, w którym już istniejące pliki (txt lub xml) będą edytowane kodem po stronie serwera: 640 lub 600
  • (zależy od tego, czy serwer internetowy wyświetli je, czasem niezmodyfikowany)

Chociaż minimalnymi uprawnieniami do katalogu mogą być:

• Katalog, w którym użytkownik załaduje pliki statyczne (pliki images / swf / js): 750
• Katalog, w którym administrator załaduje pliki statyczne (pliki images / swf / js): 750
• Katalog, w którym znajdują się biblioteki używane w aplikacji: 500 (lub 550) [powinno wynosić co najmniej 510]
• Katalog, w którym będą się znajdować skrypty wykonawcze / przeglądalne po stronie serwera: 500 (lub 550) [powinno wynosić co najmniej 510]
• Katalog, w którym już istniejące pliki (txt lub xml) będą edytowane kodem po stronie serwera: 750 lub 700
  • (zależy od tego, czy serwer internetowy będzie stąd wyświetlał pliki, czasem niezmodyfikowane)

Jeszcze raz - twój serwer musi mieć uprawnienia do „wykonywania” w każdym katalogu powyżej tego, do którego potrzebuje dostępu - więc nawet jeśli serwer nie będzie obsługiwał plików z danego katalogu, powinniśmy mu udzielić uprawnień do wykonywania.

Dawanie serwerowi dostępu do odczytu większości plików jest dość powszechne (więc zmień te z 500 na 550). Domyślne „nieco bezpieczne” uprawnienia to zwykle 755 dla katalogów i 644 dla plików - brak uprawnień do wykonywania, każdy może czytać, a tylko użytkownik może pisać - zauważysz, że znaczna większość plików w systemie Linux ma takie uprawnienia.

Należy pamiętać, że „inne” uprawnienia odnoszą się do każdego użytkownika systemu, który nie jest właścicielem ani w grupie (tj. Wszystkich pozostałych użytkowników systemu). Utrzymywanie restrykcji „innych” uprawnień jest dobre, ponieważ ci użytkownicy są nieznani - nie udzieliliście im wyraźnego pozwolenia. Inne uprawnienia są często najłatwiejsze do wykorzystania w zainfekowanym systemie (np. Jeden z powodów, dla których / tmp jest wspólnym celem).

W kontekście powyższego nie sądzę, aby twoje dwa ostatnie pytania były tak istotne. Ustaw uprawnienia do katalogu na 550 (i uprawnienia do pliku na 440), a następnie przyznaj użytkownikowi uprawnienia do zapisu dla wszystkich katalogów, w których aplikacja będzie zapisywać (np. Katalog: 750; plik: 640).

(Oczywiście będziesz potrzebować uprawnień do zapisu, aby przesłać pliki - ale jeśli chcesz, możesz je później usunąć - prawdopodobnie jednak, jeśli ktoś pisze do katalogu, do którego tylko właściciel może pisać - Twoje konto zostało naruszone - który jest jednym z nich powodów utrzymania ograniczających uprawnień).

Posiadanie minimalnego zestawu uprawnień do wykonania zadania jest normalne. Jeśli masz serwer WWW i użytkowników, którzy dzielą wspólną grupę, możesz usunąć potrzebę udzielenia dostępu o. Uprawnienia są również powiązane z użytkownikami. Wygląda na to, że źle zrozumiałeś uprawnienia ósemkowe.

1. 555 r-xr-xr-xnie jest rw-rw-rw. Ponieważ jest to katalog, aby tworzyć / usuwać pliki, musisz xustawić, więc 750 rwxr-x---byłoby dobrym miejscem do rozpoczęcia. Umożliwia to użytkownikowi, który jest właścicielem katalogu, dodawanie / usuwanie plików i dostęp do nich wszystkim członkom wspólnej grupy.
2. To samo co 1. powyżej.
3. Jeśli są to pliki naprawdę statyczne niż 050, dałoby to dostęp do serwera WWW, jednak utworzenie plików w pierwszej kolejności 750 byłoby minimum.
4. To samo co 3 powyżej.
5. Wartość 070 byłaby minimalna, aby serwer mógł czytać i zmieniać pliki, ale pliki muszą zostać utworzone, aby 770 był prawdopodobnie bardziej realistyczny.

Zasadniczo należy używać trybów 0755, 0775 lub 2775 w katalogach (bit SGID w katalogach, w BSD i Linux, jeśli system plików jest zamontowany z semantyką BSD, spowoduje, że powiązanie grupy nowych plików będzie zgodne z ustawieniami katalogu nadrzędnego, a nie domyślny GID twórcy pliku). Pozwala to wszystkim użytkownikom przeglądać (chdir do i przez) i czytać (uruchomić komendę ls lub wykonać wywołania systemowe readdir / read) w tych katalogach. Alternatywy dodają opcje grupy / zapisu i, jak wspomniano, bit SGID w katalogach, mogą pomóc zachować wszystkie pliki i podkatalogi powiązane z odpowiednią grupą.

Dla plików zwykle używa się 0644 lub ewentualnie 0664 (do odczytu na świecie i do zapisu grupowego lub nie). Oczywiście do skryptów i plików binarnych CGI należy dodać bit x; a dla niektórych szczególnych sytuacji, przy wyjątkowo dobrze przetestowanych plikach binarnych, można dodać bity SUID lub SGID. Normalnie UNIX i Linux zignorują bit SUID / SGID w skryptach i honorują jego semantykę tylko dla natywnych kompilowanych plików wykonywalnych. Jednak możesz prowadzić swoją stronę pod czymś takim jak Apache z jakimś modułem, takim jak „setuidhack”, którego można użyć, aby serwer sieciowy honorował bity SUID / SGID nawet na interpretowanych skryptach. (Odbywa się to za pomocą statycznego demona HTTP () wprowadzającego każdy plik i używającego własnego niestandardowego kodu fork () / execve (), interpolującego poprawny ciąg interpretera w wektorze execve (), zamiast po prostu przekazać plik wykonywalny „

To tylko najbardziej ogólne wytyczne. Nie są one „idealne” do wszystkich sytuacji i zdecydowanie powinieneś skonsultować się z dokumentacją serwera WWW i dowolnej aplikacji lub frameworka, który instalujesz i konfigurujesz ... i prawdopodobnie przedtem skonsultujesz się z ekspertem ds. Bezpieczeństwa UNIX udostępniać żadnych plików, kodu lub serwerów do publicznego Internetu.