Czy mogę utworzyć * super * superużytkownika, aby móc faktycznie mieć użytkownika, który może odmówić uprawnień do rootowania?

34

Pomyślałem, że korzystne może być posiadanie użytkownika z uprawnieniami wyższymi niż użytkownik root.

Widzisz, chciałbym zachować wszystkie działania i prawie wszystkie istniejące uprawnienia użytkownika root dokładnie tak, jak są teraz.

Chciałbym jednak mieć możliwość odmawiania uprawnień do rootowania w bardzo odizolowanych przypadkach.

Jedną z zalet tego byłoby, żebym mógł zapobiec instalacji niektórych niechcianych plików podczas aktualizacji. To tylko przykład jednej z możliwych korzyści.

Ponieważ aktualizacje apt-get są uruchamiane przez użytkownika root lub z uprawnieniami sudo, apt-get ma możliwość zastępowania niektórych niechcianych plików podczas aktualizacji.

Gdybym mógł odmówić tych uprawnień do tych poszczególnych plików, mógłbym ustawić je jako łącze uproszczone /dev/nulllub ewentualnie mieć pusty plik zastępczy, który mógłby mieć uprawnienia, które odmawiałyby zastąpienia pliku podczas aktualizacji.

Ponadto nie mogę nie wspomnieć o linii, która została wypowiedziana w wywiadzie z jednym z twórców Ubuntu, gdy facet powiedział coś o tym, w jaki sposób użytkownicy lepiej ufają „nam” (odnosząc się do twórców Ubuntu) „, ponieważ mamy root ”, który był odniesieniem do sposobu przeprowadzania aktualizacji systemu z uprawnieniami administratora.

Po prostu zmiana procedury instalacji, aby powiedzieć, że obejście tego problemu absolutnie nie jest tym, co mnie interesuje. Teraz, gdy mój umysł ma upodobanie do możliwości odmawiania dostępu do katalogu głównego, chciałbym wymyślić sposób, aby to zrobić tylko po to, aby to zrobić.

Właśnie o tym pomyślałem i jak dotąd nie spędziłem czasu na tym pomyśle i jestem całkiem pewien, że można to wymyślić. Jestem jednak ciekawy, czy zostało to już zrobione, czy może nie jest to nowy pomysł lub koncepcja.

Zasadniczo wydaje się, że powinien istnieć sposób na super-użytkownika, który miałby uprawnienia poza systemem tylko o jeden stopień.


Uwaga: Chociaż uważam, że zaakceptowana odpowiedź najbardziej pasuje do kryteriów, bardzo podoba mi się odpowiedź @CR. również.

Chciałbym utworzyć rzeczywistego użytkownika wyżej na drzewie (mnie), ale chyba będę musiał usiąść pewnego dnia, kiedy będę miał czas, aby to rozgryźć.

Ponadto nie próbuję tutaj wybierać Ubuntu; Nie użyłbym tego jako mojej głównej dystrybucji, gdybym czuł się z tym negatywnie.

mchid
źródło
4
O jakich plikach mówisz i dlaczego? „ zapobiegaj instalowaniu niektórych niechcianych plików _” sugeruje, że pliki nie istnieją (normalnie) i chcesz je zatrzymać; ale „co uniemożliwiłoby zastąpienie pliku podczas aktualizacji. sugeruje, że pliki już istnieją (z prawdopodobnie pożądaną zawartością) i nie chcesz nowych wersji.
TripeHound,
6
Należy pamiętać, że każda metoda, która zapobiega apt(nad) zapisywaniu plików, może prowadzić do błędu, przerywając proces aktualizacji. aptnastępnie odmówi wykonania jakichkolwiek aktualizacji lub instalacji, dopóki „problem” nie zostanie rozwiązany.
Dubu,
6
„Po prostu zmiana procedury instalacji, aby powiedzieć, że obejście tego problemu absolutnie nie jest tym, co mnie interesuje.” Być może tak, ale ogólnie jest to właściwy sposób rozwiązania problemu, jak stwierdzono. Ograniczenie roota można zrobić (formalnie root-in-userland nie jest na tym samym poziomie dostępu co tryb jądra) i istnieją systemy do jego osiągnięcia, ale jest to sprzeczne z filozofią Unixa i podstawowymi zasadami bezpieczeństwa. Ogólnie rzecz biorąc, gdy ktoś ma „częściowy” root, wyjątkowo trudno jest usunąć z czarnej listy wszystko, czego mógłby użyć, aby uzyskać „pełny” root. Wolę dać root tylko zaufanemu kodowi.
Kevin
8
@mchid: root ma pełną kontrolę. Właśnie o to chodzi. Aby nie mieć pełnej kontroli, musisz zaprzeczyć tak wielu rzeczom, że nie wygląda już jak root (np. Nie instaluje modułów jądra, nie montuje dowolnych urządzeń itd.). Jeśli nie chcesz uruchamiać rzeczy jako root, nie uruchamiaj ich jako root. Zamiast tego rozdaj możliwości (z wyjątkiem wszystkich równoważnych z rootem , nie przejmuj się nimi) lub uruchom demona takiego jak polkitd, który wykonuje operacje rootowania w imieniu procesów innych niż root.
Kevin
4
@mchid: To jest problem: Istnieje wiele sposobów obejścia twoich ograniczeń przez programy. O ile nie umieścisz na czarnej liście wszystkich tych sposobów, każdy program uruchamiany jako „ograniczony root” może nadal zostać pełnym rootem, kiedy tylko zechce. Więc cały twój plan to nic innego jak szarada teatru bezpieczeństwa.
Kevin,

Odpowiedzi:

83

„Użytkownik”, którego chcesz, nazywa się LSM: moduł bezpieczeństwa systemu Linux. Najbardziej znane to SELinux i AppArmor.

W ten sposób można uniemożliwić niektórym plikom binarnym (i ich procesom potomnym) wykonywanie pewnych czynności (nawet jeśli ich identyfikator UID jest root). Ale możesz zezwolić na te operacje gettyi ich procesy potomne, abyś mógł to zrobić ręcznie.

Hauke ​​Laging
źródło
2
Ale jeśli ich identyfikator UID jest rootem, czy nie mogą zmienić uprawnień selinux, które uniemożliwiają im dostęp?
curious_cat
11
@curious_cat: Tak, oczywiście, musisz odmówić procesowi „ograniczonego rootowania” możliwości zmiany / podniesienia własnego pozwolenia! Ludzie, którzy napisali SELinux, już o tym pomyśleli ...
Peter Cordes,
8
@curious_cat Możesz skonfigurować LSM, aby zmiana ich konfiguracji w czasie wykonywania była całkowicie niemożliwa. Musisz wtedy zrestartować komputer i podać parametr jądra.
Hauke ​​Laging,
5
@Joshua Jeśli Twoja kopia apt-get używa Rowhammera, masz większe problemy.
Draconis,
3
@corsiKa Po pierwsze, chcesz ograniczyć osoby, które mogą uruchomić komputer, do osób, które faktycznie znajdują się na komputerze, ponieważ systemy są podatne na ataki podczas uruchamiania. Wywołanie ponownego uruchomienia przez sieć jest w porządku, ale nie pozwala na kontrolę, ponieważ uruchamia się. Po drugie, zasadą bezpieczeństwa komputera jest to, że nie możesz nic zrobić, gdy atakujący ma fizyczny dostęp, ponieważ wtedy równie dobrze mogą zanurzyć wszystko w LN2 / przełączyć sprzęt / etc. Tak, więc, ktoś, kto może zmienić rozruch komputera, jest ogólnie zakładany, że „wygrał” maszynę.
HTNW
51

Nie rozumiesz pojęcia rootużytkownika.

Mówiąc rootwprost , znajduje się na „szczycie drzewa”.

Co jeśli zdecydujesz, że któregoś dnia będziesz mieć „super super użytkownika”, a następnie w przyszłym miesiącu „super super super użytkownika” (!). Jak daleko „w górę” drzewa chciałbyś się posunąć? Jak byś przetasował wszystkie uprawnienia i hierarchię, aby to zadziałało? Kto jest zawsze na szczycie? Ktoś musi być na górze i tak jest root. Koniec opowieści.

Rozwiązania podane tutaj - w tym AppArmor i SELinux - tak naprawdę tego nie zmieniają. Pozwalają po prostu dokładniej kontrolować ziarno nad rootuprawnieniami i procesami.

Wydaje mi się, że proces aktualizacji nie jest odpowiedni dla pożądanego rezultatu. Ale to wcale nie jest wina rootużytkownika. Zamiast nadmiernie komplikować rzeczy, pomyśl o rootużytkowniku uprawnień najwyższego poziomu, a potem wszystko inne, musisz pracować w dół.

Wiem, że niektórzy to zaznaczą, ale w hierarchii użytkowników nie ma wyższego poziomu, a wszystkie inne rozwiązania po prostu dają nieco inną kontrolę nad tym, jak rootdziałają uprawnienia. Ale nie tworzą nowego użytkownika z wyższymi uprawnieniami.

Nie możesz mieć użytkownika z „większą liczbą uprawnień” niż rootdlatego, że rootreprezentuje najwyższy możliwy poziom uprawnień. Używanie wyrażenia typu „więcej kontroli niż root” jest sprzecznością - rootma pełną kontrolę i wszystkie możliwe uprawnienia, więc nie można nic ponad tym zrobić.

Andy
źródło
Byłbym na szczycie, a nie root, koniec historii. Ponieważ nie ma wyższego poziomu w hierarchii użytkowników, jest to dokładnie powód, dla którego chciałbym utworzyć wyższego użytkownika.
mchid
Chociaż tego właśnie chcę: kontrolować uprawnienia i procesy rootowania, abym mógł odmówić zgody na rootowanie. Jeśli mogę w jakiś sposób odmówić uprawnień do rootowania bez tworzenia nowego użytkownika za pomocą SELinux lub AppArmor, to chyba nie potrzebuję nowego użytkownika. Chcę pełnej kontroli, większej kontroli niż root.
mchid
16
Nie możesz mieć użytkownika, który ma „więcej uprawnień” niż root. To jest cały problem. Użytkownik, którego chcesz utworzyć, jest zasadniczo użytkownikiem root. Musisz podejść do tego w inny sposób, np. Utworzyć użytkownika z rootuprawnieniami, a następnie odrzucić te, w których chcesz mieć lepszą kontrolę. To, o co pytasz („więcej kontroli niż root”) nie jest możliwe, a nawet nic!
Andy,
@mchid Więc tak naprawdę chcesz zmienić nazwę bieżącego użytkownika root na mchid, utworzyć nowego użytkownika o nazwie root i sprawić, aby apt-get i inni używali nowego użytkownika innego niż root?
Odalrick
W niektórych systemach rootnie ma uprawnień do bezpośredniego dostępu do sprzętu. Jeśli wyłączysz ładowanie modułów jądra, możesz zablokować rootowanie nad całkowitą kontrolą nad sprzętem ( /dev/memi tym podobne). Nie bardzo istotne dla uprawnień systemu plików, ponieważ nie użyłbyś apt-get, który rozmawiał bezpośrednio z twoim kontrolerem SATA lub NVMe ... Ale technicznie istnieje stan „więcej uprawnień niż root” i nazywa się to trybem jądra. : P
Peter Cordes
26

Jeśli chcesz tylko zapobiec zmianie / usunięciu plików lub katalogów, po prostu ustaw na nich flagę niezmienną.

chattr +i <file>

Nawet root nie będzie mógł nic z nimi zrobić, chyba że flaga zostanie usunięta. Możliwe jest również użycie systemu kontenera / przestrzeni nazw, aby uniemożliwić dostęp do konta root, ale wydaje się, że to przesada w stosunku do potrzeb.

CR.
źródło
11
Ale root może usunąć flagę.
sebasth
10
apt, jak prawie wszystko, nie użyje chattr do usunięcia tej flagi.
CR.
13
@sebasth: Prawidłowo, ale skrypty instalacyjne Apt, dpkg i dla poszczególnych pakietów (normalnie) nie zmieniają atrybutów pliku. Zamiast tego po prostu zawiodą i będą narzekać, gdy spróbują zmienić pliki za pomocą niezmiennej flagi.
David Foerster,
4
@TripeHound Więc OP chce apt-getodnieść sukces w zastępowaniu pliku, a jednocześnie zachować ten plik nienaruszony? To jest trochę sprzeczne, śmiem twierdzić.
Dmitrij Grigoryev
3
@DmitryGrigoryev To brzmi jak oni chcą apt-get, aby myśleć , że się udało, ale pozostawiając jeden lub więcej plików niezmienione. Nie mówią, które pliki ani dlaczego, ale, jak mówisz, nieco sprzeczne - i podatne na „dziwne zachowanie” w przyszłości.
TripeHound,
9
  • Zamiast mieć super-super-użytkownika, możesz ograniczyć rootowanie. zobacz Jakie są różne sposoby ustawiania uprawnień do plików itp. w GNU / Linux

  • Istnieje również AppArmor i SELinux.

  • I / lub skonfiguruj sudo, aby nie oddawać pełnych uprawnień roota. Możesz to ustawić tak, aby użytkownik mógł uruchamiać tylko wcześniej uzgodnione polecenia, z wcześniej uzgodnionymi argumentami.

  • Możesz także użyć wirtualizacji, aby ograniczyć rootowanie:

    • cgroups, przestrzenie nazw, chroot itp. (doker robi to)
    • Xen
    • Virtualbox
  • Zobacz także etckeeper: ta wersja narzędzia kontroluje /etckatalog i synchronizuje się z apt. Domyślnie nie jest bezpieczny, złośliwa instalacja mogłaby go sabotować, ale można też zmusić go do wypchnięcia zmian do zaporowego repozytorium kopii zapasowych.

  • Ogólne zastosowanie kontroli wersji w przypadku zaporowego repozytorium kopii zapasowych. Pomaga to w przypadkowym, celowym uszkodzeniu i awarii sprzętu.


Zaporowe repozytoria kopii zapasowych mogą znajdować się na innej maszynie, w Internecie lub na innej maszynie wirtualnej (lub hoście maszyny wirtualnej).

ctrl-alt-delor
źródło
8

W przypadku oprogramowania takiego jak APT , które podczas normalnej pracy wymaga dostępu do prawie całego systemu, ograniczenie jest problematyczne. Nawet jeśli uniemożliwisz mu dostęp do niektórych części systemu, najprawdopodobniej istnieje więcej niż wystarczających możliwości obejścia tego problemu przez złośliwego dystrybutora. Na przykład, zastępując bibliotekę lub tylko plik binarny lub dodając złośliwą zmianę konfiguracji, której nieograniczony root będzie w końcu używał.

W zależności od tego, ile chcesz nałożyć ograniczenia, niektóre skrypty instalacyjne mogą się zepsuć.

Aby poznać sposoby ograniczania aplikacji i użytkowników, możesz napisać zasadę AppArmor lub SELinux. Taka polityka, która jest bardziej obsługiwana, zależy od twojej dystrybucji: Debian ma lepszą obsługę AppArmor, podczas gdy dystrybucje oparte na Fedorze / RHEL domyślnie włączają SELinux.

Zarówno AppArmor, jak i SELinux działają na zasadach białej listy , które zawierają reguły pozwalające (lub odmawiają) określonych działań. Zasady są stosowane do procesu w exec , podobnie użytkownicy mogą być ograniczeni, gdy zasady są stosowane do ich procesów podczas logowania. Dobrze przemyślanej polityki nie można obejść (jeśli nie uwzględniono błędów jądra). Ograniczony proces działający jako root (identyfikator użytkownika 0) jest ograniczony przez skonfigurowane zasady i nie można go zmienić, chyba że jest to wyraźnie dozwolone w zasadach.

Język strategii AppArmor definiuje regułę odmowy , której można użyć do zbudowania polityki czarnej listy . Dobrym miejscem do rozpoczęcia pracy z AppArmor są strony podręcznika AppArmor , wiki i sprawdzanie istniejącej konfiguracji w Twojej dystrybucji /etc/apparmor.d/.

Wiele materiałów do administrowania i programowania SELinux znajduje się na wiki SELinux . Polityka referencyjna SELinux jest hostowana na github.

sebasth
źródło
7

Nie mogę uwierzyć, że nikt nie wspominał o trafnym przypinaniu ...

Kilka lat temu Microsoft wydał łatkę, która przerwała komputery z systemem Windows 10 od rozmowy ze starymi kontrolerami domeny Samba NT4. Kiedy problem został znaleziony, przypięliśmy pakiet Samba, aby pozostać w bieżącej wersji, i aptnadal działał poprawnie.

Pełny przewodnik po Debianie dobrze wyjaśnia ten proces:

W /etc/apt/preferences(lub nowy plik poniżej /etc/apt/preferences.d/) dodaj tekst, aby określić, który pakiet i wersję:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Sprawdź w dokumentacji dokładną składnię, ale jest to szybki i brudny sposób, w jaki przypięliśmy wersję pakietu. Root może to ominąć, jak root zawsze, ale to rozwiązuje problem menedżerów pakietów próbujących automatycznie uaktualnić pakiety na twoim komputerze.

UWAGA: Ta odpowiedź zakłada, że ​​masz problem z XY

Kanadyjczyk Luke REINSTATE MONICA
źródło
Sam odpowiedziałem na wiele problemów XY na askubuntu. Jednak apt jest tylko przykładem i to doprowadziło mnie do tego pomysłu. Bardziej interesuje mnie aspekt całości „korupcja władzy i absolutna korupcja władzy”. Całkowita i absolutna władza nad moim systemem doprowadziła mnie przede wszystkim do systemu Linux. Uświadomienie sobie, że moja moc nie zawsze jest absolutna ponad rdzeniem, jest trochę niepokojące; kusząca jest idea władzy absolutnej.
mchid
Wydaje mi się też, że to trochę problem XY, ale tutaj jest „jak odmówić uprawnień do rootowania, gdy root jest superużytkownikiem?”
mchid
1
@mchid nie polega na odmawianiu uprawnień do rootowania, ale na odmawianiu dostępu do programu działającego jako root.
John Keates,
6

To jest właściwie dość proste.

Root to Twój „superużytkownik”

Utwórz konto o nazwie „admin” i daj mu wszystkie uprawnienia root'a, z wyjątkiem tego, którego nie chcesz.

Następnie utwórz użytkownika o nazwie bob i pozwól mu „zostać administratorem”. Używając su, a nawet sudo.

Teraz masz zwykłego użytkownika (bob) superużytkownika, który może wykonywać czynności administracyjne (admin) i superużytkownika (root).

Jeśli chcesz zmienić nazwę „root” na coś innego, możesz to zrobić. Technicznie liczy się tylko identyfikator użytkownika (0).

Coteyr
źródło
Gdybym miał normalnego użytkownika (bob), superużytkownika, który może robić rzeczy administracyjne (admin) i superużytkownika (root), nie rootowałbym nadal robiąc wszystkich rzeczy administratora z procesami w tle, cronjobs i inne rzeczy jako identyfikator użytkownika (0)?
mchid
nie, jeśli nie chcesz. Większość usług pozwala wybrać, który użytkownik ma pracować. Możesz to skonfigurować, aby użytkownik admin był tym, który uruchamia procesy. Jest kilka wyjątków, ale niewiele.
coteyr
Czy nie musiałbym przejść i ustawić wszystkie te procesy indywidualnie?
mchid
3
Tak się dzieje, gdy próbujesz złamać standardowe konwencje. Myślę, że musisz lepiej zrozumieć, w jaki sposób i dlaczego systemy uprawnień są w środowisku * nix.
Shauna
2
Zgadzam się z Shauna, wydaje się, że brakuje ci podstawowej wiedzy na temat systemu uprawnień * nix. Jest bardzo potężny, ale nie przypomina okien.
coteyr
3

Jeśli chcesz po prostu zapobiec instalowaniu określonych plików, ograniczenie uprawnień administratora nie jest dobrym sposobem na zrobienie tego. Warto również zauważyć, że konwencjonalne odpowiedzi (pliki niezmienne lub LSM) nie będą działać w konkretnym przypadku użycia, ponieważ APT (i większość innych menedżerów pakietów) wyskoczy, jeśli nie będą mogli zainstalować plików.

Prawdziwe pytanie, które chcesz zadać, to:

Czy istnieje sposób, aby uniemożliwić APT instalowanie określonych plików?

To coś zupełnie innego niż to, o co pytasz na wielu poziomach.

Teraz, jeśli chodzi o to pytanie, sam nie jestem w 100% pewien, ale wiem, że wielu innych menedżerów pakietów ma opcje zapobiegające instalowaniu określonych plików (na przykład system Portage Gentoo ma opcję INSTALL_MASK=, która faktycznie akceptuje powłokę -styluj pasujące wzorce rzeczy, których nie należy instalować). Byłbym bardziej niż chętny, aby założyć się, że taka opcja istnieje dla APT (lub ewentualnie samego dpkg).

Austin Hemmelgarn
źródło
Naprawdę: „Czy istnieje sposób, aby uniemożliwić APT instalowanie określonych plików?” to nie moje pytanie; to tylko przykład i to, co przyszło mi do głowy. Nowy Firefox jest dostarczany z dodatkami i instaluje te pliki nawet po ich usunięciu przez użytkownika za pomocą nowych aktualizacji. To nie jest problem; właśnie to uświadomiło mi, że chcę jeszcze większej kontroli nad moim systemem. Doceniam jednak twoją logikę, ponieważ sam w ten sposób odpowiedziałem na kilka pytań, więc dziękuję za wkład.
mchid
dpkg-divert robi to: unix.stackexchange.com/a/157896/70847
mchid
1

Umieść kopię zapasową w bezpiecznym miejscu. Po każdej instalacji / aktualizacji natychmiast zamień określone pliki z kopii zapasowej. Dlatego nie ma błędów, które mogłyby zepsuć instalację, ale nadal otrzymujesz plik (i), które chciałeś zachować.

WGroleau
źródło
1

Pracuj z zamontowanego napędu

Zauważ, że jest to głównie konceptualna odpowiedź, ale myślę, że powinna działać i być zgodna z tym, co chcesz osiągnąć.

Niech system X będzie twoim działającym systemem, a system Y innym systemem, który kontrolujesz

  1. Zamontuj katalog z Y jako dysk w X
  2. Ustaw prawa w taki sposób, aby użytkownik root X miał prawa do wszystkiego na tym zamontowanym dysku, z kilkoma wyjątkami

Teraz masz swój „działający root”, który może zrobić prawie wszystko, i masz swój „super root”, rzeczywiste konto root systemu Y, które może naprawdę zrobić wszystko.

Dennis Jaheruddin
źródło
Podoba mi się ten pomysł, chociaż chciałbym to zrobić na działającym systemie.
mchid
1

Możesz uruchomić hiperwizora typu 1, takiego jak hypervisor Xen, i mieć go jako hosta wirtualnego gościa. Hiperwizor kontroluje wirtualny system operacyjny gościa na poziomie „głębszym” niż root, ponieważ ma kontrolę nad (wirtualnym) sprzętem, na którym działa system operacyjny gościa.

Możesz zaprogramować hiperwizora do manipulowania systemem operacyjnym gościa na różne sposoby, w tym zmiany uprawnień, tworzenie i stosowanie kopii zapasowych, przechwytywanie niektórych zmian lub instrukcji w systemie operacyjnym gościa w celu wprowadzenia dodatkowej funkcjonalności, sprawdzania poprawności itp. Byłby to prawidłowy, potencjalnie przydatny sposób zaimplementować system uniksowy z „użytkownikiem” (właściwie funkcją hiperwizora) do „robienia rzeczy, których nawet root nie potrafi”

Wydaje mi się, że takie podejście jest prawdopodobnie przesadne

Nathan Smith
źródło
W jaki sposób hiperwizor uniemożliwia użytkownikowi z uprawnieniami administratora wykonywanie jakichkolwiek czynności na maszynie wirtualnej gościa?
fpmurphy
Ta odpowiedź zaczyna się dobrze, ale potem gramatycznie idzie na manowce (wtedy czyta się w niewłaściwy sposób, a przynajmniej ambicje). Naprawiłem.
ctrl-alt-delor
1
@ fpmurphy1 hiperwizor może przechwytywać wywołania systemowe, stosować zasady itp. w celu egzekwowania arbitralnych ograniczeń dla użytkownika root lub dowolnej innej części systemu-gościa. Może moja odpowiedź nie jest dobra, ponieważ jest to zdecydowanie za dużo pracy, chyba że masz prawdziwy przypadek użycia w przedsiębiorstwie lub coś w tym stylu ...
Nathan Smith
@ ctrl-alt-delor Dzięki za naprawę, ale nie sądzę, że problem stanowiła gramatyka. Wyjaśniłem jednak, co chciałem powiedzieć, i doceniam informację zwrotną, że moje myśli na początku nie były jasne
Nathan Smith
1
@ fpmurphy1 w ramach gościa masz pełny root. Jednak nie jest to ten sam root, co root na hoście. Dlatego jest to mniejszy katalog główny niż katalog główny hosta. Docker pozwoli na lepszą integrację, ale nadal nakłada ograniczenia na rootowanie.
ctrl-alt-delor
1

Spójrz na cgroups i przestrzenie nazw Linuxa jako alternatywną metodę osiągnięcia tego typu celu, a także oparte na nich narzędzia, takie jak Docker i lxd .

Narzędzia te pozwalają między innymi ograniczać, które części systemu plików może zobaczyć proces działający jako „root”, ograniczać, które procesy są dla niego widoczne, i zapewnić tylko pewne możliwości użytkownikowi „root”.

smw
źródło
0

ODINSTALUJ sudo

Co powiesz na odinstalowanie sudo i dowiązanie symboliczne /bin/sudo /bin/false? Połącz to z upewnieniem się, że rootnie można się zalogować sshi zablokowałeś system.

To sprawia, rootże Super * Super Użytkownik, a wszyscy inni podlegają temu.

W przypadku plików zastąpionych podczas aktualizacji po prostu nie rób żadnych aktualizacji. Bardziej realistycznie, zmień uprawnienia plików na 440lub444 dlatego nie może być zapisany. Lub umieść je w repozytorium git, więc jeśli zostaną nadpisane, można je przywrócić.

użytkownik176717
źródło
Widzisz, nadal chcę robić aktualizacje i nadal chcę, aby root robił prawie wszystkie rzeczy, które normalnie robi root. Chcę jednak móc powiedzieć „zrób z siebie” lub „nie, nie możesz tego zrobić”, tak jak władza rodzicielska mogłaby to zrobić dla potomstwa. W tej chwili Root jest jak władza rodzicielska w moim systemie, a wszystkie małe dzieci mówią „mamo mamo?” kiedy używają sudo. To jest w porządku. Jednak prawie każda osoba na tej planecie jest potomkiem kogoś. Wygląda na to, że niektóre odpowiedzi tutaj
brzmią,
. . . ta babcia i dziadek to matki i ojcowie mamy i taty. Chciałbym poprosić dziadka, aby zamieszkał w moim systemie, ponieważ w tej chwili rootem jest tata domu, a dziadek może powiedzieć tacie, co ma robić, ponieważ dziadek jest ojcem taty :)
mchid
Wygląda na to, że dodałeś zbyt wielu ludzi z mocami sudo. Dostosuj sudoersplik, aby tylko wybrani użytkownicy mogli sudo wykonywać wstępnie wybrane polecenia.
user176717,
Mam tylko dwóch użytkowników w pliku sudoers, w tym root. Próbowałem użyć porównania, aby wyjaśnić, w jaki sposób niektórzy ludzie nie rozumieją mojego pytania i co chciałbym osiągnąć.
mchid
Wygląda na to, że ludzie czują, że nie może być żadnego użytkownika wyższego niż root w taki sam sposób, jak bardzo małe dziecko uważa, że ​​ich mama i tata nie mogą mieć rodziców. Nie głosowałem też za bardzo.
mchid