Mamy mały problem na serwerze. Chcemy, aby niektórzy użytkownicy mogli np. Być sudo
rootem, 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?
sudo
aby udzielić uprawnienia tylko określonej aplikacji z uprawnieniami administratora. W ten sposób użytkownik nie będzie mógł zmienić hasła rootasudo
tych użytkowników? Jeśli im nie ufasz, nie dawaj imsudo
dostę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
)sudo
isetuid
może rozwiązać większość problemów.Odpowiedzi:
Cóż, taki jest problem, który sudo ma rozwiązać, więc ta część jest dość łatwa.
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 reboot
ale nic innego, umożliwiając jednocześnie zatrudniony-as-system-administratoruser3
zrobić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 -i
lubsudo
do powłoki (sudo bash
na 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 root
sudo 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).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.
źródło
:)
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
sudo
należ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
su
ipasswd
poleceń 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/sudoers
w 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
sudo
udzielenie 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
.k5login
pliku.Cytuję odpowiednie części:
Jednak mogę się mylić. Wciąż przeglądam dokumentację i jeszcze nie wypróbowałem Kerberos.
źródło
<tr id="thisistheid"...
) do komentarza (np. W Chrome kliknij prawym przyciskiem myszy iInspect 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/...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 o
uid=0
wspólnej nazwietoor
(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/passwd
i/etc/shadow
(skopiowaćroot
linie).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
toor
konta jest banalne ; więc jedyną korzyścią jest oddzielne hasło.Alternatywnie możesz zajrzeć do alternatywnych mechanizmów uwierzytelniania, tj.
ssh
Kluczylibnss-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ę.
źródło
toor
zmiany hasła roota; zapewnia tylko drugie hasło do rootowania.toor
Konta odzyskiwania są powszechną praktyką (choć niezadowoloną) na Uniksie od dziesięcioleci.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, npsudo bash
. za pomocą . Ale po prostu nie powinieneś tam iść.źródło
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.
źródło
root
uż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.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.
źródło
Nie wiem, czy będzie to praktycznie wykonalne, ale oto jeden brudny hack:
/etc/passwd
plik do innej lokalizacji, zanim zadzwonisz do rzeczywistejsudo
sudo
/etc/passwd
plikWiem, że jest wiele rzeczy plus-minus, które musisz rozważyć, aby to osiągnąć. W końcu to brudny hack
źródło
vipw
robią już przyjaciele.root
może edytować „inną lokalizację” posudo
.Stwierdzenie, które
sudo
służy tylko do przyznania roota i nie ma już żadnej ochrony, jest rażąco fałszywe.Użyć
visudo
do zmodyfikowania pliku sudoers. Oto przykładowa linia:redsandro
to nazwa użytkownika, na który zezwalamy. Połóż%
z przodu, aby zastosować do grupy.ALL
to nazwa tej reguły. Sudoerzy mogą zrobić znacznie więcej niż tylko przyznawać globalne uprawnienia. Tam jednak komplikuje się.=
nie wymaga wyjaśnieniaALL:ALL
czyta 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_komendaNależy pamiętać, że chociaż
sudo
uż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
źródło
sudo vi
dostępu użytkownikowi, ponieważ chcę, aby mógł on edytować pliki konfiguracji systemu. Że użytkownik następnie robi:!/bin/bash
w środkusudo vi
sesji. 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 nicsudo -i
.)sudoedit
. Możesz konkretnie określić, które pliki powinny być w staniesudoedit
. To jest wman sudoers
.(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)
źródło
Twoje wymaganie to:
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.
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.
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.
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.
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.
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:
źródło
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 ...)
źródło
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.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/passwd
i 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.
źródło
Wymaganie nie jest technicznie możliwe. Jak już elokwentnie skomentowano, przyznanie użytkownikowi nieograniczonych lub nawet bardziej ograniczonych
sudo
praw 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
passwd
programu, 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 tymsudo bash
).W szczególnych (rzadkich) okolicznościach, jeśli całkowite zaufanie nie jest możliwe i nie jest możliwe przerwanie
sudo
dostę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
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).
źródło
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.
źródło
Możesz ograniczyć dostęp do sudo w swoim
/etc/sudoers
plikuAby w pełni wyjaśnić składnię / etc / sudoers, użyjemy przykładowej reguły i podzielimy każdą kolumnę:
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
passwd
do tego polecenia, wszystko będzie dobrzeźródło
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=0
albo utworzyć prosty cron, który okresowo resetuje hasło roota.źródło
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:
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
źródło
sudo
jest bardzo różny odsu -
. 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ć ...Jednym ze sposobów byłoby zagwarantowanie, że
/etc
nie będzie to możliwe do zapisu. Przez nikogo, o ile może być wsudoer
pobliż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 blocker
sprzę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
/bin
i/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ść
/etc
zapisu ...)źródło