Źle ustawiony chmod / 777. Problemy?

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ć?

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.

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ą.

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

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.