Źle ustawiony chmod / 777. Problemy?

33

Próbowałem uruchomić, chmod -R 777 ./ale skończyło się na pisaniu chmod -R 777 /i ustawieniu 777na całej maszynie. Co może pójść źle? Jak mogę to naprawić?

Vinnycx
źródło
co może pójść nie tak w systemie? czy przestanie działać?
Vinnycx
6
Oczywiście są problemy. SSH na przykład zawiedzie.
ceving
2
SSH kończy działanie, jeśli katalog domowy jest czytelny na całym świecie. Ustawienie wszystkiego na 777 jest jak robienie wszystkiego jako root.
od
3
Zobacz także serverfault.com/questions/364677/why-is-chmod-r-777-destructive, który zawiera bardziej szczegółowe informacje na temat tego, co pójdzie nie tak.
Gilles „SO- przestań być zły”

Odpowiedzi:

46

Problemy? Tak, dużo. Czy można to naprawić? Pewnie. Szybszy niż ponowna instalacja? Prawdopodobnie nie.

Moje zalecenie to ponowna instalacja. Zachowaj kopię zapasową istniejącego systemu i przywróć listę pakietów oraz zawartość plików w /etci /var. Ponieważ /usr/localprawdopodobnie możesz przywrócić uprawnienia ręcznie. W przypadku /homei /srvmusisz przywrócić uprawnienia z kopii zapasowych.

Jeśli jest to system z wieloma lokalnymi użytkownikami, zauważ, że uczynienie niektórych plików czytelnymi dla świata ujawniło pewne rzeczy, które powinny pozostać poufne.

  • Twoja lista haseł jest teraz zagrożona: lokalni użytkownicy mieli dostęp do zakodowanej listy haseł i mogli spróbować użyć siły. Powiadom o tym swoich użytkowników.
  • Wszystkie prywatne dane użytkownika (klucze ssh, przechowywane hasła, e-mail, cokolwiek innego, co użytkownicy uznają za poufne) zostały udostępnione wszystkim użytkownikom lokalnym. Powiadom o tym swoich użytkowników.

Jeśli naprawdę chcesz spróbować naprawić (bardziej ćwiczenie edukacyjne niż praktyczna droga odzyskiwania), najpierw przywróć uprawnienia kilku plików. Zauważ, że chociaż większość plików jest teraz zbyt otwarta, w kilku brakuje niezbędnych bitów setuid . Oto kroki, które powinieneś zrobić przede wszystkim. Pamiętaj, że nie jest to wyczerpująca lista, tylko próba uczynienia systemu ledwie funkcjonalnym.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Następnie musisz przywrócić wszystkie uprawnienia wszędzie. W przypadku plików poniżej /usrmożna ponownie zainstalować pakiety za pomocą jednego z następujących poleceń, w zależności od dystrybucji:

  • Jeśli używasz Debiana, Ubuntu lub innej dystrybucji opartej na APT, możesz uruchomić apt-get --reinstall install
  • Jeśli korzystasz z Arch Linux, możesz wykonać pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, zakładając, że jesteś na Live CD, a instalacja Arch jest zainstalowana /newarch.

W przypadku plików poniżej /etci /var, które nie będą działać, pozostanie ich tyle, ile są: musisz zreplikować uprawnienia do działającej instalacji. W przypadku plików poniżej /srvi /hometrzeba będzie przywrócić dane z kopii zapasowych. Jak widać, równie dobrze możesz zainstalować ponownie.

Gilles „SO- przestań być zły”
źródło
6
Zgoda, chyba że jesteś ekspertem, nie masz prawie żadnej szansy na naprawienie tej sytuacji bez pełnej ponownej instalacji lub przywracania z kopii zapasowych. Pozostawienie systemu bez zmian jest zbyt niebezpieczne.
Arrowmaster
3
Jeśli w systemie są użytkownicy, szkoda mi ich.
Jürgen A. Erhard
19

Na początku możesz tego nie zauważyć, ale wiele rzeczy może i pójdzie nie tak. Głównym problemem jest to, że cały model bezpieczeństwa dla całego systemu jest uszkodzony. To jak mieć ciało bez skóry, organy w powietrzu. Zostanie zainfekowany, ponieważ nie ma tak działać. Nawet jeśli wydaje się, że działa przez kilka minut, musisz to wyczyścić.

Najlepszym sposobem byłoby rozpoczęcie od zera. W ten sposób znacznie zmniejszysz ryzyko i zapewnisz czystszy wynik w krótszym czasie. Jeśli masz odpowiednie kopie zapasowe, nie powinno to być zbyt trudne.

Jeśli spróbujesz to wyczyścić, głównym sposobem byłoby powiedzenie menedżerowi pakietów dystrybucji, aby ponownie zainstalował WSZYSTKO w systemie, w tym nadpisanie plików konfiguracyjnych. Następnie użyj dowolnego systemu weryfikacji, który musi przejrzeć i upewnij się, że żaden z nich nie jest oznaczony jako posiadający pliki z nietypowymi uprawnieniami. Następnie przejrzyj takie rzeczy, jak katalogi domowe użytkowników i zresetuj wszystko masowo do rozsądnych uprawnień, a następnie przeprowadź kilka rzeczy, które powinny mieć specjalne uprawnienia (np. Pliki kluczy ssh). Na koniec wykonaj pełne wyszukiwanie systemu dla wszystkich oznaczonych jako 777 i przejrzyj listę (powinna być mała, jeśli dokładnie wykonałeś pozostałe kroki) i przeprowadź je kolejno, upewniając się, że powinny być takie, jakie są.

Caleb
źródło
Ale oprócz bezpieczeństwa, co może pójść nie tak z aplikacjami? Czy przestaną działać? Czy bezpieczeństwo jest tutaj najważniejsze?
Vinnycx,
Bezpieczeństwo jest największym problemem, ale wiele programów, szczególnie za kulisami, takich jak rejestrowanie demonów, cron itp. Zawiedzie z różnych powodów, zamiast narażać się na niebezpieczną sytuację, którą widzą.
Caleb
cron przestanie działać tylko z powodu 777?
Vinnycx
1
Istnieje kilka różnych systemów cron, ale żaden szanujący się cron nie powinien wykonywać zadań w cronie roota, gdy plik crontab jest dostępny do zapisu na całym świecie! Również demon pocztowy, który obsługuje powiadomienia cron, powinien narzekać z innych powodów.
Caleb
10

ROZWIĄZANIE: TESTOWAŁEM TO W CENTOSIE

Ten facet uratował moją pracę! (Musisz jakoś uzyskać dostęp)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) Aby zresetować identyfikatory i identyfikatory plików i katalogów:

for u in $(rpm -qa); do rpm --setugids $u; done

2) Do uprawnień do plików i katalogów

for p in $(rpm -qa); do rpm --setperms $p; done

następnie ręcznie zmień uprawnienia do tych plików:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart
saul scv
źródło
5

Niektóre programy świadome bezpieczeństwa nie uruchomią się, jeśli niektóre pliki mają zbyt „utracone” uprawnienia. Jak powiedział @ceving, sshdjest to najbardziej typowe z tego.

Najważniejsze, co może pójść nie tak, to teraz, że każdy użytkownik może otwierać, odczytywać i zapisywać dowolny plik w systemie. Dwa powody, dla których jest to złe, to: A) jeśli złośliwy użytkownik przejmie kontrolę nad systemem poprzez exploit lub błędną konfigurację, może teraz zmodyfikować wszystko w twoim systemie, i B) możesz usunąć wszystko, co chcesz, nawet jeśli nie jesteś rootem, więc właśnie zlekceważyłeś większość zabezpieczeń, które nie działają jako root.

Jeśli wcześniej nie utworzyłeś kopii zapasowej uprawnień, jesteś w sytuacji. Możliwe, że możesz utworzyć skrypt, który „pobiera” listę uprawnień ze świeżo zainstalowanego systemu, a następnie „stosuje” je do wszystkiego w systemie. Jednak nie mam pod ręką takiego skryptu.

LawrenceC
źródło
Ale oprócz bezpieczeństwa, co może pójść nie tak z aplikacjami? Czy przestaną działać? Czy bezpieczeństwo jest tutaj najważniejsze?
Vinnycx,
Tylko kilka aplikacji, które odmawiają uruchomienia, jeśli uprawnienia są zbyt luźne. Bezpieczeństwo jest największym problemem. Ale to także stabilność systemu. Jeśli zrobisz teraz coś rm -rf /jak normalny użytkownik, zatrzymasz swój system.
LawrenceC
Które aplikacje mogą przestać działać?
Vinnycx
Oprócz SSH? Co jeszcze może zawieść? Muszę teraz, jeśli mogę na jakiś czas opuścić system.
Vinnycx
5
@Vinnycx: Nie, nie możesz. Jest uszkodzony. Priorytetem powinno być naprawienie tego. W przeciwnym razie spodziewaj się, że Twoje usługi zawiodą Cię pojedynczo, a hakerzy zjedzą Twoje dane. Pozostawienie / * @ 777 nie jest opcją.
Caleb