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/null
lub 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.
źródło
apt
(nad) zapisywaniu plików, może prowadzić do błędu, przerywając proces aktualizacji.apt
następnie odmówi wykonania jakichkolwiek aktualizacji lub instalacji, dopóki „problem” nie zostanie rozwiązany.Odpowiedzi:
„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 operacjegetty
i ich procesy potomne, abyś mógł to zrobić ręcznie.źródło
Nie rozumiesz pojęcia
root
użytkownika.Mówiąc
root
wprost , 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
root
uprawnieniami i procesami.Wydaje mi się, że proces aktualizacji nie jest odpowiedni dla pożądanego rezultatu. Ale to wcale nie jest wina
root
użytkownika. Zamiast nadmiernie komplikować rzeczy, pomyśl oroot
uż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
root
działają uprawnienia. Ale nie tworzą nowego użytkownika z wyższymi uprawnieniami.Nie możesz mieć użytkownika z „większą liczbą uprawnień” niż
root
dlatego, żeroot
reprezentuje najwyższy możliwy poziom uprawnień. Używanie wyrażenia typu „więcej kontroli niż root” jest sprzecznością -root
ma pełną kontrolę i wszystkie możliwe uprawnienia, więc nie można nic ponad tym zrobić.źródło
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 zroot
uprawnieniami, 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!root
nie 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/mem
i 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. : PJeśli chcesz tylko zapobiec zmianie / usunięciu plików lub katalogów, po prostu ustaw na nich flagę niezmienną.
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.
źródło
apt-get
odnieść sukces w zastępowaniu pliku, a jednocześnie zachować ten plik nienaruszony? To jest trochę sprzeczne, śmiem twierdzić.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.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:
Zobacz także
etckeeper
: ta wersja narzędzia kontroluje/etc
katalog 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).
źródło
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.
źródło
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
apt
nadal 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ę: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
źródło
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).
źródło
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).źródło
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ć.
źródło
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
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.
źródło
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
źródło
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”.
źródło
ODINSTALUJ
sudo
Co powiesz na odinstalowanie
sudo
i dowiązanie symboliczne/bin/su
do/bin/false
? Połącz to z upewnieniem się, żeroot
nie można się zalogowaćssh
i 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
440
lub444
dlatego nie może być zapisany. Lub umieść je w repozytorium git, więc jeśli zostaną nadpisane, można je przywrócić.źródło
sudoers
plik, aby tylko wybrani użytkownicy mogli sudo wykonywać wstępnie wybrane polecenia.