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?

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.

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:
bob@FOOBAR.ORG
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, bob@FOOBAR.ORGnie 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.

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

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ść.

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.

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.

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

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

(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)

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:

• Linux Integrity Measurement Architecture / Extended Verification Module (IMA / EVM) oraz
• Trusted Platform Modules (TPM).

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

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.

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

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.

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

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.

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

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