Dlaczego „chmod -R 777 /” jest destrukcyjny?

255

To jest kanoniczne pytanie dotyczące uprawnień do plików i dlaczego 777 jest „destrukcyjny”.

Nie pytam, jak rozwiązać ten problem, ponieważ istnieje mnóstwo odniesień do tego już w usłudze Server Fault (reinstalacja systemu operacyjnego). Dlaczego w ogóle robi coś destrukcyjnego?

Jeśli kiedykolwiek użyłeś tego polecenia, prawie natychmiast zniszczyłeś swój system operacyjny. Nie jestem pewien, dlaczego usunięcie ograniczeń ma jakikolwiek wpływ na istniejące procesy. Na przykład, jeśli nie mam dostępu do odczytu i po krótkim błędzie w terminalu nagle mam teraz dostęp dobrze ... dlaczego to powoduje uszkodzenie Linuksa?

linux permissions chmod samwise
źródło
2
Wstrzymuję oddech, kiedy zobaczyłem to pytanie.
Alireza Savand,

Odpowiedzi:

344

Przede wszystkim drobna terminologia nitpick: chmodnie usuwa uprawnień. To ZMIANY im.

Teraz sedno problemu - tryb 777oznacza „Każdy może czytać, pisać lub uruchamiać ten plik” - Zezwoliłeś każdemu na (efektywne) wykonywanie, co tylko zechce.

Dlaczego to takie złe?

  1. Po prostu pozwalasz wszystkim czytać / modyfikować każdy plik w systemie.
    • Pożegnaj się z bezpieczeństwem haseł na pożegnanie (każdy może odczytać plik cienia i złamać hasło, ale po co zawracać sobie głowę? Po prostu ZMIEŃ hasło! To o wiele łatwiejsze!).
    • Pożegnaj się z bezpieczeństwem dla swoich plików binarnych na pożegnanie (ktoś może po prostu napisać nowy loginprogram, który pozwala im za każdym razem).
    • Pocałuj pliki na pożegnanie: jeden użytkownik przekierowuje rm -r /i to wszystko. OS został poinformowany, aby pozwolił im robić, co chcieli!
  2. Wkurzyłeś każdy program, który sprawdza uprawnienia do plików przed uruchomieniem.
    sudo, sendmaili wiele innych po prostu nie będzie już działać. Zbadają kluczowe uprawnienia do plików, zobaczą, że nie są tym, czym powinny być, i wykopią komunikat o błędzie.
    Podobnie sshpsuje się okropnie (pliki kluczy muszą mieć określone uprawnienia, w przeciwnym razie są „niepewne” i domyślnie SSH odmówi ich użycia).
  3. Usunąłeś bity setuid / setgid z programów, które je miały.
    Ten tryb 777jest w rzeczywistości . Wśród elementów tej wiodącej cyfry są cyfry i . Większość programów, które są setuid / setgid, mają ustawiony ten bit, ponieważ muszą działać z pewnymi uprawnieniami. Teraz są zepsute.0777setuidsetgid
  4. Złamałeś /tmpi/var/tmp Inna sprawa, w tym wiodących ósemkowej cyfry, które dostał zero'd jest sticky bit- To, co chroni pliki w /tmp(i /var/tmp) przed usunięciem przez osoby, które nie są ich właścicielami.
    Istnieje (niestety) wiele źle zachowujących się skryptów, które „czyszczą”, wykonując rm -r /tmp/*i bez ustawionego bitu /tmp , możesz pocałować wszystkie pliki w tym katalogu na pożegnanie.
    Zniknięcie plików scratch może naprawdę zdenerwować niektóre źle napisane programy ...
  5. Spowodowałeś spustoszenie /dev /proci podobne systemy plików
    Jest to większy problem na starszych systemach Unix, gdzie /devjest prawdziwy system plików, a zawarte w nim elementy to specjalne pliki utworzone za pomocą mknod, ponieważ zmiana uprawnień zostanie zachowana podczas ponownego uruchamiania, ale w dowolnym systemie zmiana uprawnień urządzenia może powodować poważne problemy, od oczywistych zagrożeń bezpieczeństwa (każdy może odczytać każdy TTY) do mniej oczywistych potencjalnych przyczyn paniki jądra.
    Credit to @Tonny for pointing out this possibility
  6. Gniazda i rury mogą się zepsuć lub mieć inne problemy. Gniazda i rury mogą ulec całkowitemu pęknięciu lub zostać narażone na złośliwe wstrzyknięcie w wyniku zapisu na całym świecie.
    Credit to @Tonny for pointing out this possibility
  7. Sprawiłeś, że każdy plik w systemie jest wykonywalny
    . Wiele osób ma .w swojej PATHzmiennej środowiskowej (nie powinieneś!) - Może to spowodować nieprzyjemną niespodziankę, ponieważ teraz każdy może upuścić plik o dogodnej nazwie jak polecenie (powiedz makelub lsi spróbuj nakłonić Cię do uruchomienia złośliwego kodu.
    Credit to @RichHomolka for pointing out this possibility
  8. W niektórych systemach chmodzresetuje listy kontroli dostępu (ACL).
    Oznacza to, że możesz skończyć z koniecznością ponownego utworzenia wszystkich list ACL oprócz ustalania uprawnień wszędzie (i jest to rzeczywisty przykład polecenia niszczącego).
    Credit to @JamesYoungman for pointing out this possibility

Czy działające już części systemu będą nadal działać? Prawdopodobnie przynajmniej przez jakiś czas.
Ale następnym razem, gdy będziesz musiał uruchomić program, zrestartować usługę lub zabraniać nieba, ponownie uruchom skrzynkę, w której czeka cię świat bólu, ponieważ punkty 2 i 3 powyżej odwrócą swoje brzydkie głowy.

voretaq7
źródło
1
Przynajmniej w niektórych systemach /tmpzostanie naprawiony po ponownym uruchomieniu. Chociaż wszystko inne wydaje się być zepsute. Przynajmniej na maszynie wirtualnej, którą właśnie przetestowałem, wydaje się, że ponowne uruchomienie naprawiło /tmpuprawnienia. Gdzieś musi być coś w skrypcie startowym.
Zoredache
@Zoredache Systemy, które używają tmpfszwykle same się naprawiają, te, które mają / tmp na dysku mogą (w zależności od ich skryptów startowych)
voretaq7 28.02. O
45
+1 za wskazanie, że setuid i setgid zostaną wyeliminowane. Jest to niezwykle destrukcyjny aspekt. Spróbuj uruchomić find / -perms -4000 -type fi find / -perms -2000 -type fzobaczyć różne pliki binarne, które opierają się na tych flagach.
Kyle Smith
2
Wpisanie czegoś takiego jak „less foo.txt” nie spowodowałoby, że plik o nazwie less.txt leżałby bez względu na ustawiony bit wykonywalny. Musiałbyś mieć katalog less.txt na swojej drodze i musiałbyś wpisać „less.txt foo.txt” - to nie jest przypadkowa sprawa. Nawet jeśli używasz uzupełniania powłoki, zatrzyma się na mniej i nadal będziesz musiał dodać .txt. Aby wywołać losowy plik tekstowy z wykonywalnym zestawem bitów, musisz ./nameoffile.txt.
The Real Bill
3
@Deji everyonejest zdefiniowana jako związek zestawie tym użytkownika, który jest właścicielem pliku, użytkownicy w grupie, która jest właścicielem pliku, a użytkownicy, którzy nie spełniają żadnego z tych kryteriów (dosłownie trzy cyfry ósemkowe uprawnień: User, Group, i Other). Innymi słowy, każdy użytkownik mający dostęp do systemu . („Dostęp” w tym kontekście może być kontem powłoki, tak jak normalnie bym to rozwiązał, ale obejmuje również dostęp przez formularz internetowy / CGI, który zapisuje dane na dysk: wwwUżytkownik może teraz zapisywać do dowolnego pliku w systemie , co oznacza, że ​​również przypadkowi użytkownicy).
voretaq7,
102

Jedną z głównych rzeczy jest to, że istnieje wiele narzędzi, takich jak ssh / sudo, które sprawdzają uprawnienia systemu plików dla kluczowych plików konfiguracyjnych. Jeśli uprawnienia są nieprawidłowe, narzędzia te ulegają awarii, ponieważ oznaczałoby to poważny problem z bezpieczeństwem. W moim systemie testowym Debiana i być może w innych, możliwość logowania się nie udaje, prawdopodobnie dlatego, że binarny login lub coś w PAM ma sprawdzanie uprawnień.

Tak naprawdę nie jest tak, że system jest zniszczony - chodzi o to, że wiele narzędzi zaprojektowano tak, aby natychmiast ulegały awarii, gdy uprawnienia są błędne.

Jeśli zrestartujesz system po chmod 777 -R /jego uruchomieniu, uruchomi się i możesz uruchomić procesy, które nie mają wyraźnych kontroli uprawnień. Tak więc system nie jest tak naprawdę martwy, a jedynie nieco bezużyteczny według projektu .

Zoredache
źródło