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.

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

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

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.

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

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.

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

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

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

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

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.

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

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

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