Dostęp root, który nie może zmienić hasła roota?

66

Mamy mały problem na serwerze. Chcemy, aby niektórzy użytkownicy mogli np. Być sudorootem, ale z zastrzeżeniem, że użytkownik nie może zmienić hasła roota. Oznacza to, że nadal możemy zalogować się na tym serwerze i zostać rootem bez względu na to, co zrobią inni użytkownicy.

Czy to jest możliwe?

244an
źródło
32
Możesz użyć, sudoaby udzielić uprawnienia tylko określonej aplikacji z uprawnieniami administratora. W ten sposób użytkownik nie będzie mógł zmienić hasła roota
SHW
24
DLACZEGO potrzebujesz sudotych użytkowników? Jeśli im nie ufasz, nie dawaj im sudodostępu. Pamiętaj też, że najlepiej root nie powinien mieć hasła , ale powinieneś użyć innych sposobów uwierzytelnienia. (Które użytkownik nadal będzie mógł „zhakować”, nawet jeśli chcesz sformatować tekst /etc/passwd)
Anony-Mousse,
3
Co dokładnie muszą zrobić ci użytkownicy?
Olivier Dulac,
4
Co będą robić ze swoimi uprawnieniami do rootowania? Może być lepsze rozwiązanie niż to, o czym myślisz.
sparticvs
23
Jest to jeden z tych „Czy Bóg może uczynić głaz tak duży, że sam nie może go podnieść?” wpisz pytania. Jeśli masz dostęp do konta root, możesz zrobić wszystko, dlatego dostęp do konta root najlepiej jest podawać z rozwagą. sudoi setuidmoże rozwiązać większość problemów.
bsd

Odpowiedzi:

57

Chcemy, aby niektórzy użytkownicy mogli np. Być sudorootem,

Cóż, taki jest problem, który sudo ma rozwiązać, więc ta część jest dość łatwa.

ale z zastrzeżeniem, że użytkownik nie może zmienić hasła roota.

Możesz, jak wskazał SHW w komentarzu, skonfigurować sudo, aby niektórzy użytkownicy mogli wykonywać tylko root jako root. Oznacza to, że można zezwolić user1 zrobić sudo services apache2 restart, pozwalają użytkownik2 zrobić, sudo rebootale nic innego, umożliwiając jednocześnie zatrudniony-as-system-administrator user3zrobić sudo -i. Dostępne są instrukcje, jak skonfigurować sudo w ten sposób, lub możesz wyszukać (lub zapytać) tutaj. To jest problem do rozwiązania.

Jednak użytkownik, któremu przyznano zdolność do sudo -ilub sudodo powłoki ( sudo bashna przykład), może zrobić wszystko. Jest tak, ponieważ zanim sudo uruchomi powłokę, samo sudo jest poza obrazem. Zapewnia kontekst bezpieczeństwa innego użytkownika (najczęściej root), ale nie ma wpływu na to, co robi wykonywana aplikacja. Jeśli ta aplikacja zostanie uruchomiona, passwd rootsudo nie może nic z tym zrobić. Pamiętaj, że można to zrobić również za pośrednictwem innych aplikacji; na przykład wiele bardziej zaawansowanych edytorów zapewnia funkcje umożliwiające wykonanie polecenia przez powłokę, powłokę, która zostanie wykonana z efektywnym identyfikatorem użytkownika tego procesu edytora (to znaczy root).

Oznacza to, że nadal możemy zalogować się na tym serwerze i zostać rootem bez względu na to, co zrobią inni użytkownicy.

Przepraszam; jeśli naprawdę masz na myśli „upewnij się, że będziemy w stanie zalogować się i korzystać z systemu bez względu na to, co zrobi z nim użytkownik root”, to (we wszystkich celach i celach) nie można tego zrobić. Szybkie „sudo rm / etc / passwd” lub „sudo chmod -x / bin / bash” (lub cokolwiek innego root root używa), a ty i tak jesteś prawie niezadowolony. „Prawie ukryty” oznacza „musisz przywrócić z kopii zapasowej i mieć nadzieję, że nie zrobili nic gorszego niż potknięcie palcami”. Możesz podjąć pewne kroki, aby zmniejszyć ryzyko przypadkowej wpadki prowadzącej do bezużytecznego systemu, ale nie możesz zapobiec złośliwości powodującej bardzo poważne problemy, włącznie z koniecznością odbudowy systemu od zera lub przynajmniej ze znanego dobre kopie zapasowe.

Zapewniając użytkownikowi nieskrępowany dostęp do systemu w systemie, ufasz temu użytkownikowi (w tym każdemu oprogramowaniu, które zdecyduje się wykonać, nawet tak przyziemnemu jak ls), że nie będzie miał złych zamiarów i nie zadziała przez przypadek. Taka jest natura dostępu do roota.

Ograniczony dostęp do roota np. Sudo jest nieco lepszy, ale nadal musisz uważać, aby nie otwierać żadnych wektorów ataku. A dzięki prawom dostępu root istnieje wiele możliwych wektorów ataku dla ataków eskalacji uprawnień.

Jeśli nie możesz im ufać poziomem dostępu, jaki pociąga za sobą rootowanie, będziesz potrzebować albo bardzo ściśniętej konfiguracji sudo, albo po prostu nie przyznać użytkownikowi dostępu do roota w jakikolwiek sposób, sudo lub w inny sposób.

CVn
źródło
3
Przepraszam, moja odpowiedź ma cały szum (nie całkiem rozumiem!). Twoja odpowiedź podnosi doskonałe punkty i mam nadzieję, że zostanie zaakceptowana. +1 do pana, proszę pana.
Joseph R.
@JosephR. czasem preferowana jest zwięzła odpowiedź.
David Cowden,
@DavidCowden Tak, wygląda na to, że tak jest tutaj ...
Joseph R.
1
@JosephR. Nie martw się o mnie. Społeczność Stack Exchange nie zawsze jest przewidywalna, a pytania, które mają już wiele pozytywnych opinii, zwykle przyciągają więcej. Ale dziękuję za głosowanie. :)
CVn
92

Jest to praktycznie niemożliwe. Przede wszystkim, jeśli dasz im moc rootowania , to nic nie możesz zrobić, aby powstrzymać ich przed zrobieniem czegokolwiek. W twoim przypadku sudonależy użyć, aby przyznać użytkownikom niektóre uprawnienia roota, jednocześnie ograniczając innych bez umożliwienia im rootowania .

W swoim scenariuszu trzeba by ograniczyć dostęp do sui passwdpoleceń i otwarty dostęp do prawie wszystkiego. Problem polega na tym, że nie ma nic, co można zrobić, aby uniemożliwić użytkownikom bezpośrednią edycję /etc/shadow(lub /etc/sudoersw tym przypadku) bezpośredniej zmiany hasła roota w celu przejęcia roota. I to jest najprostszy możliwy scenariusz „ataku”. Sudoerzy z nieograniczoną mocą, z wyjątkiem jednego lub dwóch poleceń, mogą obejść ograniczenia w celu przejęcia pełnego dostępu do konta root.

Jedynym rozwiązaniem, jak sugeruje SHW w komentarzach, jest sudoudzielenie użytkownikom dostępu do ograniczonego zestawu poleceń.


Aktualizacja

Istnieje sposób na osiągnięcie tego, jeśli używasz biletów Kerberos do uwierzytelniania. Przeczytaj ten dokument wyjaśniający wykorzystanie .k5loginpliku.

Cytuję odpowiednie części:

Załóżmy, że alicja użytkownika miała plik .k5login w swoim katalogu domowym zawierającym następujący wiersz:
[email protected]
Pozwoliłoby to bobowi na korzystanie z aplikacji sieciowych Kerberos, takich jak ssh (1), w celu uzyskania dostępu do konta alice przy użyciu biletów Kerberos boba.
...
Zwróć uwagę, że ponieważ Bob zachowuje bilety Kerberos dla swojego głównego zleceniodawcy, [email protected]nie miałby żadnych uprawnień, które wymagają biletów alice, takich jak dostęp do konta root do dowolnego z hostów witryny lub możliwość zmiany hasła alice.

Jednak mogę się mylić. Wciąż przeglądam dokumentację i jeszcze nie wypróbowałem Kerberos.

Joseph R.
źródło
Jak zrobiłeś to fajne odniesienie do komentarza? Spojrzałem na źródło twojej odpowiedzi i zobaczyłem () otaczające ją. Fajny sekretny kapelusz!
Joe
@Joe Czas opublikowania komentarza jest tak naprawdę linkiem do samego komentarza.
Joseph R.
@Joe Znajdź id ( <tr id="thisistheid"...) do komentarza (np. W Chrome kliknij prawym przyciskiem myszy i Inspect element), a następnie dołącz go do łącza do wątku z poprzedzającym #. W twoim przypadku (id = comment-162798) wygląda to tak: unix.stackexchange.com/questions/105346/...
Polym
1
Dzięki za odpowiedź, nie wiedziałem, czy powinienem przyjąć to czy tamto od @Michaela Kjörlinga, wybrałem jego, ponieważ ma on większy opis - potrzebny przez nooba takiego jak ja :) Jednak twój był również pomocny
244an
@ 244an Bez obaw. Poleciłbym to samo. :)
Joseph R.
17

Zakładam, że chcesz się upewnić, że masz dostęp do „awaryjnego administratora”, nawet jeśli twój prawdziwy administrator spieprzy sprawę (ale poza tym całkowicie ufasz głównemu administratorowi).

Popularnym podejściem (choć bardzo hackerskim) jest posiadanie drugiego użytkownika ouid=0 wspólnej nazwie toor(root do tyłu). Ma inne hasło i może służyć jako dostęp do kopii zapasowej. Aby dodać, prawdopodobnie będziesz musiał edytować /etc/passwdi /etc/shadow(skopiować rootlinie).

Jest prawie całkowicie bezpieczny, ale jeśli musisz tylko zabezpieczyć się przed „głównym administratorem” zmieniającym hasło bez powiadomienia, to zadziała. Wyłączenie toorkonta jest banalne ; więc jedyną korzyścią jest oddzielne hasło.

Alternatywnie możesz zajrzeć do alternatywnych mechanizmów uwierzytelniania, tj. sshKluczy libnss-extrausers, LDAP itp.

Pamiętaj, że administrator nadal może źle spieprzyć. Na przykład, blokując zaporę.

Jeśli chcesz mieć bardzo bezpieczny system, rozważ użycie SELinuksa, w którym użytkownik unixowy (np. Root) również ma rolę, która może być znacznie bardziej precyzyjna. Możesz przyznać administratorowi uprawnienia roota, ale tylko ograniczoną rolę (np. Tylko do administrowania apache). Ale to będzie wymagało sporo wysiłku po twojej stronie, aby poprawnie skonfigurować politykę.

Anony-Mus
źródło
6
To tak naprawdę nie uniemożliwia użytkownikowi toorzmiany hasła roota; zapewnia tylko drugie hasło do rootowania.
Alexis
2
-1. Sugerujesz hasło backdoor, aby administratorzy mogli odzyskać dostęp do konta root po ich utracie? Jest to po prostu błędne, a poza tym nieznośni użytkownicy mogą łatwo to wyłączyć, jak mówisz. Istnieje wiele bardziej niezawodnych sposobów konfigurowania backdoora.
Alexis
2
@alexis O to IMHO autor pytania zadał. Po co dawać -1 za to? toorKonta odzyskiwania są powszechną praktyką (choć niezadowoloną) na Uniksie od dziesięcioleci.
Anony-Mousse,
9
Jeśli jedynym celem jest zapobieganie przypadkowym zmianom haseł, jest to dobra odpowiedź. Jeśli celem jest zapobieganie złośliwemu programowi, nie jest to zbyt duża pomoc. Ponieważ OP nie powiedziało, jaki jest cel, nie wiemy.
Bobson
2
Dlatego w pierwszym zdaniu powiedziałem: „spieprzyć… poza tym, ufasz… w pełni”. To naprawdę tylko rozwiązanie „dostępu do pomocy technicznej”; nie jest to funkcja bezpieczeństwa. Użycie dodatkowych kluczy root ssh pozwala osiągnąć to samo, nie będąc hackingiem.
Anony-Mousse,
11

Istotą roota jest nieograniczone sterowanie systemem. Możesz go ulepszyć za pomocą SELinuksa (kiedyś była strona demonstracyjna, gdzie każdy mógł zalogować się jako root, ale jego moc została osłabiona przez system dostępu), ale nie o to chodzi. Chodzi o to, że jest to niewłaściwe rozwiązanie twojego problemu.

Teraz nie powiedziałeś, na czym polega twój problem, ale jeśli nie ufasz tym użytkownikom, że będą trzymać się z dala od hasła roota, nie będą mieli prawa rootować. Jeśli będą musieli administrować serwerem internetowym lub różnymi urządzeniami, napędem warp lub czymkolwiek innym, skonfiguruj rozwiązanie tego problemu. Utwórz grupę o dużej mocy, zapewnij jej cały potrzebny dostęp i dodaj ją do niej. Jeśli będą musieli wykonywać wywołania systemowe tylko do roota, napisz niektóre programy setuid.

Oczywiście użytkownik z takim dostępem (i odrobiną wiedzy) prawdopodobnie z łatwością zhakuje system, ale przynajmniej pracujesz z modelem bezpieczeństwa systemu operacyjnego, a nie przeciwko niemu.

PS. Istnieje wiele sposobów na zapewnienie sobie dostępu do konta root bez hasła; po pierwsze, jeśli jesteś w /etc/sudoers(bez ograniczeń), potrzebujesz tylko własnego hasła, aby zostać rootem, np sudo bash. za pomocą . Ale po prostu nie powinieneś tam iść.

Alexis
źródło
Problem polega na tym, że nie można powstrzymać atakującego przed rootowaniem poprzez exploita, SELinux zapewnia głęboką ochronę.
Timothy Leung,
11

Prawdopodobnie jest to możliwe, przynajmniej teoretycznie, przy użyciu SELinux . Umożliwia to skonfigurowanie znacznie bardziej precyzyjnych reguł dotyczących tego, co użytkownik lub proces jest lub nie może robić. Nawet w przypadku SELinuksa może być trudne uniemożliwienie użytkownikowi zmiany hasła roota, ale nadal jest w stanie zrobić wszystko, co trzeba.

Naprawdę zależy to od tego, co musi zrobić użytkownik, który nie może zmienić hasła roota. Prawdopodobnie łatwiej i bezpieczniej byłoby po prostu dowiedzieć się, co to jest, i udzielić tych uprawnień, używając konkretnie sudo.

rjmunro
źródło
8
Podczas gdy robienie tego za pomocą SELinux może teoretycznie być możliwe (i nie jestem przekonany), twierdzenie, że jest to bez pokazywania rzeczywistych reguł, nikomu nie pomoże.
Gilles
@Gilles, właściwie to właśnie do tego został stworzony SELinux. SELinux to warstwa wymaganych uprawnień oprócz standardowych uprawnień POSIX. Na odpowiednio skonfigurowanym komputerze SELinux dostęp do konta root jest bez znaczenia, ponieważ twoje prawdziwe uprawnienia są określone przez kontekst bezpieczeństwa i etykietowanie obiektu.
tylerl
2
Jeśli wiesz, jak to zrobić, odpowiedz na mit lub rzeczywistość: SELinux może ograniczyć użytkownika root?
Gilles,
Teoretycznie nadal może być wykonalne w SELinux; jednak konfiguracja czegoś takiego musiałaby być bardziej złożona, aby zapewnić solidne oddzielenie WSZYSTKICH plików konfiguracyjnych związanych z SELinux od „normalnego” systemu plików (do którego rootużytkownik ma pełny dostęp). W końcu „najłatwiejszą” metodą takiego rozdzielenia (z SELinux lub bez) byłoby zastosowanie czegoś takiego jak Kerberos, jak wspomniał Joseph R.
ILMostro_7
7

Być może powinieneś rozważyć umożliwienie użytkownikom dostępu root do maszyny wirtualnej lub kontenera LXC. Pozwoliłoby to im na pełny dostęp root do systemu, nie uniemożliwiając im zalogowania się na hoście lub podjęcia działań administracyjnych.

DSimon
źródło
Byłoby to bezpieczniejsze niż wiele opcji IMHO.
Starszy Geek
5

Nie wiem, czy będzie to praktycznie wykonalne, ale oto jeden brudny hack:

  1. Napisz skrypt / program otoki, który skopiuje /etc/passwdplik do innej lokalizacji, zanim zadzwonisz do rzeczywistejsudo
  2. Zezwól zwykłemu użytkownikowi na korzystanie sudo
  3. Po zakończeniu zadania lub po wyjściu z sudo przywróć /etc/passwdplik

Wiem, że jest wiele rzeczy plus-minus, które musisz rozważyć, aby to osiągnąć. W końcu to brudny hack

SHW
źródło
3
Zawsze istnieje możliwość, że złośliwy użytkownik przeczyta ten skrypt i nuke kopię zapasową.
Joseph R.
To także prawie to, co vipwrobią już przyjaciele.
CVn
Rozważ to program i mając tylko dostęp do roota
SHW
1
rootmoże edytować „inną lokalizację” po sudo.
Anony-Mousse,
5
Dlaczego UDZIELAM dostępu root do potencjalnie złośliwego użytkownika? Jako root, trywialne jest instalowanie tylnych drzwi, które nie zależą od przejścia przez sudo i / lub owijkę ...
Alexis
5

Stwierdzenie, które sudosłuży tylko do przyznania roota i nie ma już żadnej ochrony, jest rażąco fałszywe.

Użyć visudodo zmodyfikowania pliku sudoers. Oto przykładowa linia:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command
  • redsandroto nazwa użytkownika, na który zezwalamy. Połóż %z przodu, aby zastosować do grupy.
  • ALLto nazwa tej reguły. Sudoerzy mogą zrobić znacznie więcej niż tylko przyznawać globalne uprawnienia. Tam jednak komplikuje się.
  • = nie wymaga wyjaśnienia
  • ALL:ALLczyta jako (who_to_run_it_as: what_group_to_run_it_as). W ten sposób możesz zezwolić na uruchomienie polecenia, ale tylko w kontekście określonego użytkownika lub grupy.
  • NOPASSWD: nakazuje wyłączenie monitu o podanie hasła.
  • /path/to/command pozwala na określenie konkretnych poleceń ścieżka_do_kolumny, inna_komenda

Należy pamiętać, że chociaż sudoużytkownicy domowi najczęściej używają go do eskalacji uprawnień roota, można go używać do kontroli dostępu do określonych poleceń w bardziej szczegółowy sposób.

Bibliografia

  • z mojej innej odpowiedzi tutaj
RobotHumans
źródło
Ta odpowiedź wyjaśnia, jak skonfigurować sudo dla ograniczonego dostępu do roota, ale byłoby znacznie lepiej, gdyby odpowiedź brzmiała tak i gdzie to powinno się udać.
CVn
@ MichaelKjörling zrobione
RobotHumans
3
„Rażąco fałszywe jest stwierdzenie, że sudo służy tylko do przyznawania uprawnień roota i nie ma już żadnej ochrony. Powiedzmy, że udzielam sudo vidostępu użytkownikowi, ponieważ chcę, aby mógł on edytować pliki konfiguracji systemu. Że użytkownik następnie robi :!/bin/bashw środku sudo visesji. W jaki sposób zdolność sudo do ograniczania poleceń, które użytkownik może wykonywać za pomocą sudo, pomaga chronić mój system w takich okolicznościach? (Nikt nie powiedział, że sudo nie można skonfigurować ściślej niż podejście typu wszystko albo nic sudo -i.)
CVn
6
Zrozumienie ograniczeń podejścia jest równie ważne, jak umiejętność wykonania zadania.
CVn
1
@ MichaelKjörling, myślę, że to tylko przykład. Ale dla jasności, właściwym sposobem na umożliwienie użytkownikom edycji plików konfiguracji systemu jest umożliwienie im uruchomienia sudoedit. Możesz konkretnie określić, które pliki powinny być w stanie sudoedit. To jest w man sudoers.
Matthew Flaschen
3

(Nie znam Ubuntu, ale powinien być podobny do Fedory / Red-Hat)
. Jedyne, co mogę sobie wyobrazić, ogranicza dostęp do zmiany hasła roota, nie dając pełnego dostępu roota, być może za pomocą sudo lub używania SElinux do ograniczenia dostępu do pliku haseł ... ale nie ufałbym albo z dużym dostępem, ponieważ root ma ogólnie nieograniczony dostęp i mógłby zaktualizować SElinux, ponownie oznakować plik haseł lub uruchomić jakiś wstępnie przygotowany program, aby zmienić hasło.

Jeśli nie ufasz im na tyle, aby nie zmienić hasła, prawdopodobnie nie powinieneś dawać im uprawnień roota. W przeciwnym razie zgaduję, że próbujesz uniknąć wypadków.

Jeśli próbujesz tylko chronić swój dostęp do roota, skonfiguruj program, który może przywrócić hasło roota, więc nawet jeśli zostanie zmienione, można je przywrócić przy minimalnym dostępie. (sudo dobrze sobie radzi)

9mjb
źródło
3

Twoje wymaganie to:

Mamy mały problem na serwerze [...], czyli gwarancję, że nadal możemy zalogować się do tego serwera i zostać rootem bez względu na to, co zrobią inni użytkownicy.

Z twojego pytania wydaje się, że nie masz do czynienia z przypadkowymi złośliwymi użytkownikami zamierzającymi zniszczyć twój system, ale zamiast tego masz częściowo zaufanych użytkowników, którzy od czasu do czasu mogą wyrządzić krzywdę (może studenci?). Moje sugestie dotyczą tej sytuacji, a nie całkowitego ataku złośliwych użytkowników.

  1. Uruchom serwer w środowisku wirtualnym. Będziesz mógł zamontować system plików serwera i zastąpić zmienione pliki znanymi wersjami. W zależności od przewidywanego możliwego uszkodzenia, możesz zrobić migawkę wszystkich krytycznych katalogów (/ bin, / sbin, / etc, / usr, / var, itp.) I rozwinąć migawkę, aby zastąpić uszkodzone pliki, pozostawiając resztę nienaruszony system.

  2. Uruchom system tylko do odczytu, np. Z dysku DVD-R. Jeśli możesz żyć z większością elementów systemu w stanie statycznym do następnego uruchomienia, jest to dobra opcja. Możesz również użyć magazynu kopii zapasowych tylko do odczytu ze środowiskiem wirtualnym lub załadować system podstawowy przez sieć, dzięki czemu zmiany między ponownymi uruchomieniami są znacznie łatwiejsze niż pisanie nowej płyty DVD-R.

  3. Moduły jądra. Moduły bezpieczeństwa Linux (LSM) jądra stanowią podstawę do tworzenia bezpiecznych modułów. LSM jest używany przez SELinux, ale jest także używany przez wiele mniej znanych i prostszych systemów, takich jak Smack, TOMOYO i AppArmor. Ten artykuł zawiera dobry przegląd opcji. Szanse są jedną z tych, które można skonfigurować od razu po wyjęciu z pudełka, aby uniemożliwić dostęp do zapisu do / etc / passwd, / etc / shadow lub dowolnego innego pliku (plików), nawet przez root.

  4. Ten sam pomysł jak w przypadku nr 1, ale gdy serwer nie znajduje się w środowisku wirtualnym. Serwer może być ładowany łańcuchowo do systemu operacyjnego tylko do odczytu, takiego jak dysk CD na żywo, który automatycznie montuje system plików serwera i zastępuje system podstawowy przy każdym uruchomieniu za pomocą znanych kopii. System operacyjny tylko do odczytu uruchamia się następnie w głównym systemie operacyjnym.

  5. Ponownie, zakładając, że są to użytkownicy częściowo zaufani, którzy odpowiadają przed wyższym (nauczycielem / szefem), najlepszą odpowiedzią może być Linux Audit . W ten sposób poznasz wszystkie podjęte działania związane z bezpieczeństwem i kto je podjął (będziesz wiedział, kto je podjął, ponieważ nawet jeśli wszyscy użytkownicy współużytkują konto root, najpierw wykonają sudo na swoim koncie użytkownika). W rzeczywistości możesz nawet parsować dziennik kontroli w czasie rzeczywistym i zastępować uszkodzone pliki. Nadpisany / etc / shadow? Nie ma problemu, wystarczy, że serwer monitorowania natychmiast zastąpi go znaną dobrą wersją.

Inne technologie, które warto zbadać w zależności od potrzeb:

Animizm
źródło
2

Aby uzupełnić inne odpowiedzi, przyjmuję, że scenariusz polega na tym, że postrzegasz utratę kontroli nad rootem w rzadkiej sytuacji i że w takich przypadkach dozwolone jest ponowne uruchomienie serwera. (W końcu, jeśli uważasz, że komputer został przejęty, i tak będziesz chciał go przełączyć w tryb offline).

Ogromną zaletą tego jest to, że nie trzeba nic konfigurować. Twoje pytanie brzmi: „ Zapomniałem hasła roota, jak mogę się odzyskać? ”. Odpowiedzią jest zrestartowanie komputera i wybranie trybu jednego użytkownika po uruchomieniu komputera. To daje powłokę root bez konieczności znajomości hasła. W tym momencie możesz ustawić nowe hasło. (Podobnie jak idź i napraw wszelkie uszkodzenia ...)

Darren Cook
źródło
2
Nie. Jak trafnie zauważył Michael , złośliwy użytkownik może uniemożliwić dostęp do konta root bez konieczności przejęcia hasła, po prostu psując pliki binarne. Nawet temu init=...podejściu można zapobiec usunięcie uprawnień do wykonywania z odpowiednich plików binarnych. Myślę, że lepszym rozwiązaniem w tym przypadku jest zamontowanie głównego systemu plików za pomocą LiveCD i (próba) naprawienia uszkodzeń. Z drugiej strony, jeśli uważasz, że system został przejęty, lepiej zrezygnować z przywracania z kopii zapasowej.
Joseph R.
Zgoda @JosephR; odkrywanie i naprawianie uszkodzeń jest skomplikowane, a ja po prostu ponownie instaluję. Ale zgaduję, że troska PO polegała bardziej na tym, że ktoś przypadkowo je zablokował ... celowe włamanie w pracy lub szkole jest trochę samobójcze. ;-)
Darren Cook
1
Niekoniecznie. Naprawdę złośliwy użytkownik w połączeniu z nieostrożnym / nieświadomym sysadminem może eskalować niewykryte uprawnienia. Zgadzam się, że pierwotnym zamiarem PO było raczej odpieranie niewinnych błędów niż ochrona przed złośliwymi zamiarami, ale pytanie oznaczono jako „bezpieczeństwo” i chyba po prostu z tym uciekliśmy :)
Joseph R.
2

Jeśli sklonujesz swój serwer na maszynie wirtualnej (takiej jak VirtualBox ), możesz dać nieskrępowany dostęp rootowi do osób i nadal zagwarantować, że zawsze będziesz mieć bezpośredni dostęp do partycji systemu operacyjnego gościa, a zatem zachowasz ostateczną kontrolę nad /etc/passwdi podobnie, ponieważ będziesz mieć root w systemie hosta.

Oczywiście udzielenie nieograniczonego dostępu do konta root może nadal nie być właściwym rozwiązaniem: jeśli bezpieczeństwo danych stanowi w ogóle problem lub twoją odpowiedzialność, nie możesz dać dostępu do konta root.

SevenSidedDie
źródło
2

Wymaganie nie jest technicznie możliwe. Jak już elokwentnie skomentowano, przyznanie użytkownikowi nieograniczonych lub nawet bardziej ograniczonych sudopraw oznacza, że ​​mu ufasz . Ktoś mający złe intencje i wystarczającą zdolność techniczną i wytrwałość może przejść przez wszelkie przeszkody, które zostaną wprowadzone.

Jednak zakładając, że możesz ufać swoim użytkownikom, że nie mają złych zamiarów, możesz wprowadzić ograniczenia dotyczące zmiany hasła, co jest kwestią zasad . Możesz utworzyć opakowanie dla passwdprogramu, które będzie przypominać „nie zmieniaj hasła roota”. Zakłada się, że źródłem problemu jest to, że użytkownicy, którzy zmieniają hasło roota, robią to z powodu nieporozumienia (jak być może myślenie, że zmieniają własne hasło po tym sudo bash).

W szczególnych (rzadkich) okolicznościach, jeśli całkowite zaufanie nie jest możliwe i nie jest możliwe przerwanie sudodostępu do odpowiednich, ale racjonalnie bezpiecznych fragmentów, możesz rozważyć ustanowienie sankcji organizacyjnych za zmianę hasła (lub inną określoną formę manipulowania systemem), zorganizuj monitorowanie krytycznych zasobów, aby nie było łatwo ominąć ustalone zasady - oraz być jawnym i przejrzystym na temat zasad użytkowania i monitorowania.

Aspekt monitorowania i odkrywania jest trudnym problemem technicznym, korzystającym z innego pytania, jeśli zdecydujesz się pójść tą ścieżką. Wydaje mi się, że musielibyśmy

  1. wykrywa, kiedy użytkownik zmienia tożsamość na root i śledzi wszelkie utworzone procesy;
  2. odtąd rejestruj kreacje procesów, aby zobaczyć, kto jest pierwotnym użytkownikiem odpowiedzialnym za każdy proces, i korzystaj ze zdalnego hosta, na którym pół-zaufani użytkownicy nie mają dostępu do wysyłania dzienników;
  3. użyj jakiegoś śledzenia systemu, aby zarejestrować, co się dzieje, i później dowiedzieć się, kto stoi za naruszeniem zasad.

Musielibyśmy przynajmniej rejestrować otwieranie innych niż bezpieczny zestaw plików do pisania, tworzenia procesów exec()i oczywiście wszelkich prób zmiany sieci.

Implementacja może być wykonana przez zmodyfikowane libc lub (znacznie lepsze) śledzenie wywołań systemowych.

Oczywiście niemożliwe jest, aby takie śledzenie i rejestrowanie działało w 100% poprawnie, nie jest łatwe do wdrożenia, a także wymaga dodatkowych zasobów do działania. Nie powstrzymałoby to zmiany hasła ani innych niepożądanych modyfikacji systemu, ale umożliwiłoby (bardziej prawdopodobne) znalezienie winnego użytkownika lub przynajmniej stworzyło złudzenie, że monitoruje, i sprawi, że będzie mniej zachęcające dla niektórych złych użytkowników (ale niektórzy hakerzy kochający problemy, którzy widzą fundamentalną bezskuteczność wprowadzonych środków technicznych, mogą poczuć się zachęcani do podjęcia wyzwania i próby obejścia systemu tylko dla zabawy).

FooF
źródło
1

Oryginalnie sformułowane pytanie jest bezużyteczne. Wygląda na to, że głównym celem jest „nadal mieć login”, więc mówiąc o jakimś awaryjnym wejściu, które działa na pewno, nawet z dostępem roota przyznanym innej osobie. Pozdrowienia dla Anony-Mousse, który pierwszy to wyraźnie zauważył.

Problem polega na tym, że: jeśli właściciel ma fizyczny dostęp do skrzynki, może łatwo odzyskać logiczny dostęp do systemu (pod warunkiem, że wciąż żyje :). Jeśli nie - zachowanie hasła roota nie uratuje np. Sshd down lub złej konfiguracji sieci, dlatego system i tak nie jest dostępny.

Temat dotyczący zapobiegania uszkodzeniom systemu przez osobę z uprawnieniami administracyjnymi wydaje się zbyt szeroki, aby pasował do formatu pytania SE.

Mówiąc o zdalnym wejściu awaryjnym najlepszym rozwiązaniem jest IPMI (myślę), jeśli jest dostępny. Właściciel systemu może w dowolnym momencie dołączyć dysk wirtualny, uruchomić z niego system i rozpocząć odzyskiwanie systemu.

Jeśli IPMI nie jest dostępne, można obejść dowolną odpowiednią technologię wirtualizacji, jak już zaproponowano powyżej.

Veniamin
źródło
0

Możesz ograniczyć dostęp do sudo w swoim /etc/sudoerspliku

Aby w pełni wyjaśnić składnię / etc / sudoers, użyjemy przykładowej reguły i podzielimy każdą kolumnę:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Pierwsza kolumna określa, do którego użytkownika lub grupy ma zastosowanie ta reguła sudo. W tym przypadku jest to użytkownik jorge. Jeśli słowo w tej kolumnie jest poprzedzone symbolem%, oznacza tę wartość jako grupę zamiast użytkownika, ponieważ system może mieć użytkowników i grupy o tej samej nazwie.

Druga wartość (WSZYSTKO) określa hosty, których dotyczy ta reguła sudo. Ta kolumna jest najbardziej przydatna podczas wdrażania środowiska sudo na wielu systemach. W przypadku stacjonarnego systemu Ubuntu lub systemu, w którym nie planujesz wdrażania ról sudo na wielu systemach, możesz pozostawić tę wartość ustawioną na WSZYSTKIE, czyli symbol wieloznaczny pasujący do wszystkich hostów.

Trzecia wartość jest ustawiana w nawiasach i określa, jak użytkownik lub użytkownicy, którzy użytkownik w pierwszej kolumnie może wykonać polecenie jako. Ta wartość jest ustawiona na root, co oznacza, że ​​jorge będzie mógł wykonywać polecenia określone w ostatniej kolumnie jako użytkownik root. Tę wartość można również ustawić na symbol wieloznaczny WSZYSTKIE, co pozwoli jorge na uruchamianie poleceń jak każdy użytkownik w systemie.

Ostatnia wartość (/ usr / bin / find, / bin / rm) to oddzielona przecinkami lista poleceń, które użytkownik w pierwszej kolumnie może uruchomić jako użytkownik (użytkownicy) w trzeciej kolumnie. W tym przypadku zezwalamy jorge na uruchomienie find i rm jako root. Tę wartość można również ustawić na WSZYSTKIE symbole wieloznaczne, co pozwoli jorge na uruchamianie wszystkich poleceń w systemie jako root.

Mając to na uwadze, możesz zezwolić na polecenia X w postaci przecinków i dopóki nie dodasz passwddo tego polecenia, wszystko będzie dobrze

ehime
źródło
-1

Nie ma 1/2 roota. Po przyznaniu uprawnień roota mogą robić, co chcą. Alternatywnie możesz użyć sudo, aby uruchomić ograniczoną powłokę bash lub uruchomić rbash bez uprawnień roota.

Jeśli chcesz mieć niezawodny mechanizm logowania do serwera jako root, możesz albo utworzyć innego użytkownika, uid=0albo utworzyć prosty cron, który okresowo resetuje hasło roota.

jaskółka oknówka
źródło
Łatwo jest uciec od ograniczonej bash, zobacz ten blog Sans
Franklin Piat
-1

Spróbuj dodać grupę kół zamiast sudo. sudo pozwala użytkownikowi wykonać się tak, jakby był rootem, co oznacza, że ​​nie różni się niczym od uruchamiania:

su -

stać się rootem. Główny identyfikator użytkownika = 0; UID koła = 10. Ludzie używają nazw, ale system operacyjny używa identyfikatora użytkownika. Pewne polecenia nie mogą być uruchamiane przez członka grupy kół. (Jeśli używasz koła, nie popełnij błędu dodając root jako członek grupy kół). Zajrzyj do dokumentacji Red Hata, jeśli nie wiesz, co to jest koło.

Inną opcją jest użycie klucza ssh zamiast hasła. Zakładając, że możesz być pewien, że ludzie używający sudo nie dodają swoich kluczy publicznych do pliku ~ / .ssh / authorkeys, to omija wszelkie obawy związane ze zmianą hasła roota, ponieważ hasło roota jest skutecznie ignorowane.

Jeśli wolisz ominąć rozszerzanie zaufania do tych użytkowników (aby nie dodawać własnego klucza publicznego), spróbuj użyć rozszerzonych atrybutów pliku i użyć bitu Niezmiennego. Po utworzeniu pliku ~ / .ssh / authorkeys i skonfigurowaniu / etc / ssh / sshd_config i / etc / ssh / ssh_config, jak chcesz, ustaw bit Niezmienny. Jasne, są też sposoby, żeby to zepsuć - nic nie jest idealne.

W każdym systemie poufne informacje są najwyższym ryzykiem. Osoba prowadząca program jest na szczycie stosu. Podobna myśl dotyczy umów. Prawnicy powiedzą Ci: „Nigdy nie rób interesów z kimś, z kim potrzebujesz umowy na prowadzenie interesów”. Zdrowy rozsądek mówi nam: „Nigdy nie rób interesów bez umowy”. Gdy znajdziesz kogoś, komu ufasz na tyle, by robić interesy, napisz umowę na podstawie wzajemnych potrzeb.

Wszystkie przesłane odpowiedzi, w tym moje, nie odnoszą się do fizycznego dostępu. Ktokolwiek to ma, ma kontrolę. Jeśli to nie ty, to prawdopodobnie istnieje sposób, aby uzyskać osobę fizycznie uzyskującą dostęp do maszyny w przypadku, gdy ktoś znajdzie sposób, aby uniemożliwić Ci zalogowanie się, lub jeśli znajdzie sposób, aby zalogować się nawet po tobie próbowałem temu zapobiec. Oczywiście, jeśli masz fizyczny dostęp, może nie być potrzeby żadna z tych rzeczy, chociaż i tak warto rozważyć wdrożenie pary, jeśli nie jesteś zainteresowany niewygodą.

-John Crout

John Crout
źródło
sudojest bardzo różny od su -. Zostało to wielokrotnie podkreślone, na przykład przez SHW , Josepha R. , siebie , hbdgafa i całkiem możliwe, że jeszcze kilka pól komentarzy jest zbyt krótkich, aby zawierać ...
CVn
Wszystko prawda, ale bez znaczenia. Dyskutujesz o alternatywnych sposobach rootowania i ryzykach związanych z udzieleniem dostępu do roota, ale nie ma to żadnego wpływu na „dostęp do roota, który nie może zmienić hasła roota”.
Gilles,
Prawdziwe. Pytanie jest logicznym oksymoronem; Nie może istnieć, dopóki instalacja nie zostanie zepsuta. Co dobrego ma login / konto użytkownika, na którym użytkownik nie może zmienić swojego hasła, ale ma dostęp do konta root? Dlatego oferowane sugestie dotyczą tego, co mógł oznaczać pytający; nie w sposób, w jaki napisali pytanie. Każda metoda kontroli dostępu wiąże się z nieodłącznym ryzykiem.
John Crout,
-3

Jednym ze sposobów byłoby zagwarantowanie, że /etcnie będzie to możliwe do zapisu. Przez nikogo, o ile może być w sudoerpobliżu.

Można to zrobić, montując go przez sieć i upewniając się, że z drugiej strony nie można zapisać urządzenia.

Można to zrobić za pomocą lokalnego urządzenia, które uniemożliwia dostęp do zapisu. (Wyszukaj write blockersprzęt)

Ważną częścią jest to, że ograniczenie musi obowiązywać poza koncepcją root tego komputera. Kreatywny haker znajdzie sposób na ominięcie wszystkich przeszkód, jakie stawiasz na nich w środowisku, które może kontrolować. Więc jeśli root mógłby zmienić swoje hasło, to może również sudoer.

Aby mieć pewność, że użytkownik nie może również popsuć twoich możliwości logowania, musisz mieć zamontowane tylko do odczytu /bini /sbin.

I będziesz musiał mieć skrypt, który okresowo przywraca połączenie sieciowe.

(Na marginesie: jeśli zezwalasz sudoerowi na bardzo ograniczony zestaw poleceń i dla każdego z nich zabezpieczasz, że nie mogą się z nich wyrwać / zastąpić itp., Możesz temu zapobiec, mając możliwość /etczapisu ...)

Angelo Fuchs
źródło
Montowanie / etc tylko do odczytu, chociaż być może jest to możliwe (na przykład podczas uruchamiania pivot-root w skryptach startowych initrd), istnieje ryzyko, że będzie to dość delikatna konfiguracja. Ponadto istnieje wiele rzeczy, które może zrobić użytkownik z dostępem do konta root, który utrudnia innym użytkownikom uzyskanie uprawnień roota, które nie wymagają modyfikacji w / etc.
CVn
@ MichaelKjörling Konfiguracja nie jest delikatna, używam jej często (jako lokalnych montowań tylko do odczytu).
Angelo Fuchs,
@ MichaelKjörling Dodałem kilka innych elementów, które chcesz mieć tylko do odczytu, jeśli chcesz mieć pewność, że nadal możesz się zalogować. Tak więc lista działań, które należy wykonać, jeśli zejdziesz tą drogą, nie jest taka krótka, ale jest to jedyny sposób, który „jest gwarancją, że nadal możemy zalogować się na tym serwerze i zostać rootem bez względu na to, co zrobią inni użytkownicy”.
Angelo Fuchs,
Przyznaję, że nigdy nie widziałem potrzeby wypróbowania tego, ale zdecydowanie mogę zauważyć, że ryzykowne jest to, w jaki sposób init poradzi sobie z zastąpieniem pliku / etc / inittab pod jego stopami. Lub co zrobi system, jeśli początkowe i po ponownym zamontowaniu / etc / fstab są inne. I jest / etc / mtab. Inni użytkownicy mogą chcieć zmienić własne hasła, co wiąże się z zapisem w / etc / shadow i ewentualnie / etc / passwd. A montaż / etc tylko do odczytu jest nadal tylko częściowym rozwiązaniem. Nie twierdzę, że nie może być częścią rozwiązania, ale z pewnością nie jest to pierwszy krok, jaki postawiłbym w sytuacji PO.
CVn
1
Tak. Takie postępowanie jest niebezpieczne i powoduje poważne problemy, jeśli zostanie wykonane nieprawidłowo. Nadal, o ile widzę, jest to jedyny realny sposób rozwiązania żądania OP dla użytkowników, którym należy zezwolić na rootowanie.
Angelo Fuchs,