Nie można zalogować się jako sudo w Uniksie, „sudo: musi być rootem setuid”

0

Dzisiaj zrobiłem coś szalonego: zmieniłem uprawnienia do wszystkich plików / folderów pod /usr/bin/777. Odczytywanie, zapisywanie i wykonywanie. Od tego czasu nie mogę się zalogować jako sudo. Po prostu rzuca

sudo: musi być rootem setuid

Przeczytałem w poście:

Uruchom ponownie komputer, wybierz konsolę odzyskiwania i wpisz następujące polecenia

chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo

Uruchom ponownie maszynę.

Problem polega jednak na tym, że nie mogę zalogować się jako sudo w celu ponownego uruchomienia. Aby ponownie uruchomić komputer, użytkownik musi być superużytkownikiem, np root. Nie znam też hasła do sudo. Czy jest jakiś sposób, aby to rozwiązać?

unix permissions Steve Sam
źródło
Podaj swój system operacyjny. Czy próbowałeś suużyć hasła roota?
Daniel Beck
1
Ponadto, jak to jest możliwe, aby zmienić /usr/binsię 777bez znajomości hasła sudo?
slhck 12.01.12
czy możesz opublikować, jakie wyniki uzyskasz za pomocą „ls -l / usr / bin / sudo”
daya
3
Sugeruję, aby poprosić o pomoc administratorów serwera lub innych pracowników pomocy technicznej na miejscu. Gdyby można było to zrobić zdalnie, bez sudohasła ani hasła roota, byłby to poważny problem z bezpieczeństwem. Jedynym sposobem, aby to zrobić samemu, jest wykorzystanie luk w zabezpieczeniach, takich jak inne pliki binarne setuid, skrypty uruchamiane zgodnie rootz harmonogramem i które można edytować itp.
Daniel Beck
1
Musisz zrozumieć, że nie ma czegoś takiego jak użytkownik sudo . Jeśli potrzebujesz tymczasowych uprawnień roota jako zwykły użytkownik, użyj sudo(superuserdo) i podaj hasło użytkownika, aby uruchomić polecenie as root. Aby zalogować się jako rootużytkowania sui podać hasło dla rootużytkownika.

Odpowiedzi:

1

Superuser prawdopodobnie /bin/suwyciąga cię (i ) z /etc/sudoers(i prawdopodobnie /etc/passwd) podczas pisania tego.

Jeśli nie znasz hasła administratora, aby przełączyć się na konto administratora /bin/su, to oczywiście nie jesteś prawdziwym administratorem i to jest ktoś inny. Osobą, która to naprawi, jest właściwy administrator , ponieważ otworzyłeś ogromną lukę bezpieczeństwa i stworzyłeś właściwy bałagan. Rzeczywisty superużytkownik, po zobaczeniu tego bałaganu, prawdopodobnie przeszedł w tryb BOFH i jest zajęty usuwaniem twojej zdolności do ponownego uruchamiania rzeczy pod egidą konta superużytkownika, biorąc pod uwagę, co się stanie, gdy to zrobisz.

Zasadniczo otworzyłeś okno, w którym każdy, kto ma konto na komputerze, może go złamać i uzyskać uprawnienia administratora bardzo łatwo. (Niektóre pliki wykonywalne regularnie działają pod egidą konta administratora, w odpowiedzi na cronzadania i tym podobne, są teraz dostępne do zapisu na całym świecie.) Bezpieczne porządkowanie tego to dużo pracy, ponieważ trzeba pracować na zasadzie, że każdy plik wykonywalny gdziekolwiek w systemie jest potencjalnie zagrożone. Każdy, kto mógłby zdalnie zalogować się na konto na maszynie za pośrednictwem SSH lub wykorzystać dowolny inny sposób uzyskania dostępu do powłoki jako zwykły użytkownik, mógł to zrobić.

Twój dwuliniowy post z nienazwanego postu na forum dyskusyjnym całkowicie nie ma wpływu na bezpieczeństwo tego, co zrobiłeś. Ale częściowo dlatego, że dotyczy innej sytuacji . Wpisy, które bez wątpienia oglądasz, są miejscem, w którym ludzie zmienili własność /usr/bin/sudoi nie sprawili, że można je pisać na całym świecie tak jak ty .

Twój superużytkownik, jeśli Xe zna rzeczy Xyr, nie ominie konsekwencji bezpieczeństwa. Ale Xe nie będzie zadowolony z tego, ile pracy właśnie stworzyłeś dla XEM.

Na korzyść biednego administratora:

JdeBP
źródło