Jakie ryzyko wiąże się z ustawieniem uprawnień do pliku / katalogu na 0777?


6

Obecnie nie mogę przesłać pliku do folderu internetowego. Cokolwiek zrobię, nawet ustawiając uprawnienia do folderu na 0777, nie mogę przesłać do niego pliku. Z ciekawości szukałem ryzyka związanego z ustawianiem uprawnień do plików na 0777.

Znalazłem tutaj pytanie , ale nie do końca miałem odpowiedź na to, czego szukałem.

Jestem całkowicie nieświadomy tego tematu. Jakie ryzyko jest związane?

Odpowiedzi:


7

Ustawienie 0777 na folder(a mówię tutaj o folderze, a nie pliku) nie wiąże się z żadnym ryzykiem bezpieczeństwa wykonania, jak niektórzy by twierdzili.

Execute is needed on a directory to access the inode information of the files within. You need this to search a directory to read the inodes of the files within. For this reason the execute permission on a directory is often called search permission instead.

Zobacz http://content.hccfl.edu/pollock/aunix1/filepermissions.htm

Ryzyko to:

  • każdy może czytać pliki w tym folderze (pod warunkiem, że sam plik ma ruprawnienia użytkownika / grupy próbującej go odczytać lub dla others)
  • każdy może tworzyć pliki w tym folderze (i opcjonalnie je wykonywać, ale tylko te utworzone przez tego konkretnego użytkownika)
  • każdy może usunąć pliki należące do innych osób w tym folderze (twoje pliki nie są zabezpieczone, niezależnie od właściciela / pozwolenia)

Jeśli chcesz zabezpieczyć niektóre pliki, musisz utworzyć inny folder z „normalnymi” uprawnieniami (rw tylko dla ciebie lub rw dla ciebie i twojej grupy) i umieścić w nim swoje pliki.

Z drugiej strony nikt nie mógł zamienić pliku niewykonywalnego na plik wykonywalny (chmod nie jest dozwolony, jeśli nie jesteś właścicielem pliku).

Jakie ryzyko nie jest?

Niektórzy uważają, że 0777 jest dziedziczony przez każdy plik w folderze. Jest źle . Nie możesz edytować pliku, jeśli nie masz wuprawnień tylko dlatego, że jego folder nadrzędny to 0777. Nie możesz odczytać pliku, jeśli nie ma on ruprawnień.

Jak to zabezpieczyć?

Jeśli masz dostęp do jakiejś powłoki lub jeśli twój klient FTP pozwala ci zmienić właściciela plików i wiesz, którego właściciela potrzebujesz, możesz utworzyć folder i ustawić jego właściciela na proces apache (zazwyczaj nobody, daemonlub apache) i po prostu ustaw uprawnienia 0700. Problem polega na tym, że inni użytkownicy, tacy jak ty, podczas przeglądania za pomocą klienta FTP, nie będą mogli odczytać plików utworzonych później przez PHP, co niekoniecznie jest problemem.

OK, ale co z plikami?

Nie mówię o ryzyku związanym z fileswykonywaniem, ponieważ nie ma powodu, dla którego chciałbyś wymusić xzezwolenie na plik, który nie powinien być wykonywany w pierwszej kolejności.

Jeśli jakaś aplikacja internetowa musi zapisać w istniejącym pliku, wystarczy ustawić go na 0666 (lub 0600, jeśli właścicielem jest użytkownik Apache).


Co powiesz na „każdy może ZMIENIĆ określone pliki w folderze”. Widzisz problem bezpieczeństwa, gdy folder zawiera pliki wykonywalne do pobrania, które ludzie ufają i instalują bez zadawania pytań? : p
wimvds

@wimvds Nikt nie może zmieniać plików (tylko usuwanie), muszą mieć co najmniej 0666 lub być własnością osób, które chcą je zmienić. Uprawnienia 0777 do folderu nie są dziedziczone przez pliki.

Oczywiście poprzedni komentarz zakładał, że pliki będą również do zapisu na całym świecie (na wypadek, gdybyś się zastanawiał) ... To zależy od tego, czy domyślne ustawienia doprowadzą do katastrofy bezpieczeństwa, czy nie.
wimvds

@wimvds Zredagowałem swoją odpowiedź, aby wyraźnie rozróżnić pliki i foldery

Powiedz mi jedno, kiedy tworzę katalog, używając php, czy będę właścicielem, grupą lub użytkownikiem?
Starx,

2

Każdy, kto ma dostęp do folderu (tj. xUprawnienie do każdego folderu na ścieżce) może odczytać, zmodyfikować i wykonać plik.

Jeśli jest to coś, co faktycznie można wykonać, istnieje duże ryzyko, że złośliwi użytkownicy dodadzą zły kod, a następnie poczekają na jego wykonanie, abyś mógł wykonać jakiś zły kod (np. Utworzenie kopii bashtego pliku jest ustawione na setuid i możliwe do wykonania przez atakującego) .

Jeśli korzystasz z hostingu współdzielonego, sprawdź, czy 0770 nie jest wystarczające - jeśli użytkownik FTP należy do tej samej grupy co serwer WWW, wystarczy. W takim przypadku wyżej wymienione zagrożenia zwykle nie mają zastosowania, ponieważ nigdy nie zamierzasz wykonywać czynności w docelowym folderze przesyłania, a PHP musi open_basedirograniczać dostęp innych użytkowników do twoich plików. Jeśli jednak host obsługuje również skrypty CGI (np. Przy użyciu Perla), można je łatwo obejść.


Tak więc nawet osoba odwiedzająca witrynę może usunąć plik z uprawnieniem 0777.
Starx,

Kiedy próbowałem utworzyć katalog, gdy uprawnienia do folderu wynosiły 0775, nie mogłem. Przynajmniej w końcu jestem w stanie pisać na nim za pomocą 0777. Powiedz mi jedno, kiedy tworzę katalog, używając php, będę ownerlub grouplub user.
Starx,

-1 Jak „wykonać” folder? ;-)

@Starx możesz utworzyć folder i ustawić właściciela procesu Apache (zwykle nobody, daemonlub apache) i ustawić uprawnienia 0700. Problem polega na tym, że inni użytkownicy, tacy jak Ty, podczas przeglądania za pomocą klienta FTP, nie będą mogli odczytać plików utworzonych przez PHP.

@Capsule: Ma na myśli pliki w folderze.

0

Prawdopodobnie nie odpowiadam na twoje pytanie dotyczące ryzyka, ale zgaduję, dlaczego nie możesz pisać.

Prawdopodobnie folder nadrzędny nie ma dostępu do zapisu dla tego użytkownika ...

użyj chmod ugo+w whateverfilerekursywnie czegoś w linii do folderu nadrzędnego, aż będziesz mógł w nim tworzyć pliki :)


folder nadrzędny nie musi być zapisywalny (mówimy tutaj o folderze, a nie pliku). Gdyby to była prawda, każdy folder na pełnej ścieżce musiałby być zapisywalny przez użytkownika uruchamiającego proces apache ...

Cóż, napotkałem problem polegający na tym, że nie mogłem przenieść plików z winscp do systemu linux do folderu w /var/www/cgi-bin/. Musiałem więc ustawić folder www, aby był zapisywalny!

0

Zakładając, że wykluczyłeś już kilka podstawowych ustawień bezpieczeństwa PHP (ograniczenia open_basedir i in.) - debugowanie i error_reporting(E_ALL);(upewnij się, że rejestrujesz błędy zamiast wyświetlania ich w systemach produkcyjnych) są całkiem przydatne, aby to sprawdzić: p.

Jeśli ustawisz uprawnienia do folderu na 777 (do zapisu na całym świecie), a proces nadal nie będzie mógł zapisać do tego folderu, może być uruchomiona implementacja MAC, która zapobiega właśnie tego rodzaju problemom (SELinux lub AppArmor są prawdopodobnie kandydatami, jeśli jesteś za pomocą Linuksa). W takim przypadku zmiana wprowadzonych przez nie zasad pomoże rozwiązać ten problem. Ustawienie folderu do zapisu na świecie jest możliwym problemem bezpieczeństwa (szczególnie, gdy dany folder jest wystawiony na świat zewnętrzny), a także najprawdopodobniej można go uniknąć.


Masz rację, ale teraz mogę pisać do folderu, ale nic poza podaniem 0777 nie pozwoli mi tego zrobić.
Starx,

Pod jakim względem miałem rację? Implementacja MAC czy ograniczenia oparte na PHP (open_basedir)? Jeśli jest to pierwszy, może pomóc, jeśli określisz używany system operacyjny i implementację MAC.
wimvds,

Masz rację w odniesieniu do tego, co przyjąłeś.
Starx,

Cóż, jeśli właściciel folderu jest ustawiony poprawnie (najlepiej dla użytkownika / grupy używanej do uruchamiania apache / php), to nawet 700 (lub 770 - w zależności od konfiguracji) powinno wystarczyć. Wszystko zależy więc od konfiguracji apache / php i będziesz mieć więcej szczęścia publikując to (wraz ze wszystkimi istotnymi szczegółami dotyczącymi twojej konfiguracji) na ServerFault ...
wimvds
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.