Jakie prawa dostępu nie może naruszać administrator?

Ks. Br. George powiedział w jednym ze swoich wykładów (po rosyjsku), że istnieją pewne prawa dostępu, których administrator nie może naruszyć. Oznacza to, że istnieją pewne prawa dostępu, które mogą zabronić administratorowi robienia czegoś.

Nie udało mi się znaleźć tych informacji w Internecie i jestem ciekawy, czym one są. Jest to prawdopodobnie związane z rdzeniem systemu, prawda? Może nie może zatrzymać niektórych procesów systemowych? A może nie może uruchomić procesu w trybie rzeczywistym?

To pytanie nie ma związku z SELinux (George mówił o tym tuż przed pytaniem).

acess odmowa rootowania :

rootmożna odmówić bezpośredniego dostępu do sieci. Funkcja ta jest przydatna w Internecie podłączonych hostów, gdyż wymaga, aby zalogować się jako smith, a następnie sudo.

niektóre rzeczy root nie mogą zrobić :

NIE jest to spowodowane brakiem przywilejów. Nie widzę nic, co root nie mógłby zrobić, jednak niektóre problemy techniczne mogą być postrzegane jako „zabronione”.

Jestem rootem, dlaczego nie mogę utworzyć / usunąć tego pliku, podczas gdy zwykły użytkownik może?

Jesteś na udziale NFS / samba i nie udzielono Ci konkretnej ( access=) autoryzacji. Zwykły użytkownik nie przestrzega powszechnego prawa. (patrz lokalny vs zdalny root poniżej)

Jestem rootem, dlaczego nie mogę zabić tego procesu?

Oczekuje na we / wy, a napęd fizyczny / zdalna jednostka LUN zostały odłączone, proces można zabić tylko poprzez ponowne uruchomienie.

Jestem rootem, jak zdobyć hasło Archemara?

Możesz su - archemarwszystko zmienić lub zmienić hasło Archemara, nie znając poprzedniego, ale nie możesz go odczytać (bez rejestratora kluczy), ponieważ hasła są przechowywane przy użyciu skrótu jednokierunkowego.

lokalny vs zdalny root

• Możesz być rootem na stacji / komputerze i korzystać z udziału NFS firmy / uczelni / uniwersytetu / dostawcy.
• Następnie możesz mieć tylko login użytkownika innego niż root na komputerze eksportującym NFS.

Teraz

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

wystarczy zalogować się na serwerze NFS, uruchomić ./bashi jesteś rootem na serwerze firmy / uniwersytetu.

W zwykłym przypadku jest to niepoprawne - administrator ma uprawnienia / uprawnienia do dowolnej funkcji zapewnianej przez system (1). Ta reguła się psuje, gdy włączysz SELinux do miksu. Dzięki SELinux można ograniczyć nawet uprawnienia roota, aby zabronić pewnych działań. Jednak konkretne niedozwolone działania są w dużym stopniu zależne od konfiguracji SELinuksa na komputerze lokalnym, więc nawet w przypadku SELinuksa na to pytanie nie można odpowiedzieć w sensie ogólnym.

(1) - jeśli system nie zapewnia danej funkcji, np. Nie ma funkcji jądra w czasie rzeczywistym, uważam, że stwierdzenie „root nie ma dostępu do tej funkcji” jest fałszywe, ponieważ oświadczenie to opiera się na fałszywe założenie (mianowicie, że dana funkcja jest dostępna dla każdego w tym systemie)

Z jednej strony są rzeczy, których żaden użytkownik nie może zrobić, takie jak

• twarde linki do katalogów (z powodu ograniczeń systemu plików)
• zapis na już nagranej płycie CD-ROM (ponieważ fizyka)

Ale to nie są przywileje, ponieważ nie można ich przyznać, po prostu nie są możliwe dla nikogo.

Następnie istnieją ograniczenia dla całego systemu lub jego części, które można włączyć lub wyłączyć.
Na przykład w systemie OS X istnieje możliwość zezwolenia na uruchomienie kodu tylko wtedy, gdy został podpisany przez Apple.

Nie uważam tego za faktyczny przywilej, ponieważ żaden użytkownik nie może go mieć, jeśli administrator nie może. Możesz to tylko globalnie wyłączyć.

Edycja:
Twój pomysł na plik bez bitu wykonywalnego również należałby do tej kategorii, ponieważ dosłownie nikt nie jest w stanie tego zrobić i nikt nie może uzyskać tego uprawnienia.
I nawet jeśli dajesz innemu użytkownikowi lub grupie uprawnienia do wykonania tego pliku, ale nie ma roota lub roota grupy użytkowników, root nadal będzie mógł wykonać ten plik (testowany na OS X 10.10, 10.11 i serwerze Ubuntu 15.04).

Poza tymi przypadkami, root nie ma prawie nic.
Istnieje jednak funkcja zwana trybem jądra (w przeciwieństwie do trybu użytkownika).

O ile mi wiadomo, w zdrowym systemie tylko jądro, rozszerzenia jądra i sterowniki działają w trybie jądra, a wszystko inne (w tym powłoka, z której logujesz się jako root) działa w trybie użytkownika.
Można zatem argumentować, że „samo rootowanie to za mało”. Jednak w większości systemów użytkownik root może załadować moduły jądra, które z kolei będą działać w trybie jądra, skutecznie dając rootowi sposób uruchamiania kodu w trybie jądra.

Istnieją jednak systemy (np. IOS), w których nie jest to (arbitralnie) możliwe, przynajmniej nie bez wykorzystania zabezpieczeń. Wynika to głównie ze zwiększonego bezpieczeństwa, takiego jak wymuszanie podpisywania kodu.
Na przykład w procesorach iDevices wbudowane są klucze szyfrujące AES , do których można uzyskać dostęp tylko z trybu jądra. Moduły jądra mogą uzyskać do nich dostęp, ale kod w tych modułach jądra musiałby zostać podpisany przez Apple, aby jądro je zaakceptowało.

W systemie OS X od wersji 10.11 (El Capitan) istnieje także tak zwany „tryb bez rootowania” (choć nazwa wprowadza w błąd, ponieważ root nadal istnieje), który skutecznie zabrania rootowania niektórych rzeczy, które instalatorzy mogą nadal robić.
Cytując tę doskonałą odpowiedź na AskDifferent :

Oto, co ogranicza, nawet z katalogu głównego:

• Nie możesz modyfikować niczego w / System, / bin, / sbin lub / usr (oprócz / usr / local); lub dowolne z wbudowanych aplikacji i narzędzi. Tylko instalator i aktualizacja oprogramowania mogą modyfikować te obszary, a nawet robią to tylko podczas instalowania pakietów podpisanych przez Apple.

Wspomniane „wykonanie rdzenia systemu” znajduje się pod rootkontrolą, np. Poprzez moduły jądra z możliwością ładowania. Oczywiście przy założeniu, że ładowanie modułów jądra jest obsługiwane przez jądro, nikt nie może wykonywać akcji, które są niewykonalne, nawet root.

To samo dotyczy procesów systemowych. rootwolno zabijać dowolny proces, ale nie można zatrzymać procesu działającego w trybie jądra bez naruszenia integralności jądra, więc natychmiastowe zatrzymanie takiego przetwarzania jest po prostu niemożliwe. Zauważ, że rootnie będzie odmowa zabicia tych procesów, samo zabicie po prostu nie przyniesie żadnego efektu.

Wreszcie tryb rzeczywisty: jądro Linuksa nie obsługuje go, więc ponownie nikt nie może zrobić tego, co niemożliwe, nawet root.

@Siguza wspomniał o wykonywaniu plików bez xpozwolenia, co jest całkiem możliwe dla rootużytkownika:

/lib/ld-linux.so.2 /path/to/executable

Jednym z przykładów może być zmodyfikowanie o niezmiennej pliku: Można ustawić atrybut pliku iz chattrsprawia, że niezmienne plików nawet do korzenia. Na przykład:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Zauważ, że plik wygląda jako normalny zapisywalny plik na ls -lwyjściu:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Aby zobaczyć iatrybut, musisz użyć lsattr:

# lsattr god
----i----------- god

Strona podręcznika chattr zawiera następujące informacje na temat iatrybutu:

Pliku z atrybutem `i 'nie można modyfikować: nie można go usunąć ani zmienić jego nazwy, nie można utworzyć łącza do tego pliku i nie można zapisać danych w pliku. Tylko superużytkownik lub proces posiadający zdolność CAP_LINUX_IMMUTABLE może ustawić lub usunąć ten atrybut.

Jednak root może łatwo cofnąć niezmienność:

# chattr -i god
# rm -v god
removed ‘god’

W FreeBSD nie można używać gmirrorna już zamontowanej partycji, nawet jako root:

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Nie można przechowywać metadanych na ad4s1: Operacja niedozwolona.

Musisz ustawić sysctl( kern.geom.debugflags=16), aby móc to zrobić.

rootjest uprzywilejowanym użytkownikiem, ale prawa te są nadawane przez jądro. Jądro ma więcej uprawnień niż root.

Zakładając współpracę od samego użytkownika root, rootmożna uniemożliwić dostęp do mocowań FUSE (z opcjami allow_otherlub allow_root), ale dzieje się tak, ponieważ FUSE został zaprojektowany w taki sposób. Ponieważ FUSE znajduje się na warstwie wirtualnej, może zwracać dowolny błąd, który mu się podoba, w oparciu o logikę, w przeciwieństwie do zwykłych modułów urządzeń blokowych, które starają się być tak przezroczyste i cienkie, jak to możliwe, delegując uprawnienia na inną warstwę.

Nie zapobiega to wyłączeniu opcji przez użytkownika root lub zamianie modułu FUSE na moduł, który dyskretnie odrzuca opcję, chyba że system plików zostanie ustawiony jako tylko do odczytu. Prowadzi to jednak tylko do sytuacji „kto obserwuje stróżów”: w jaki sposób można potwierdzić, że system nie kłamie? Twoja powłoka może nawet siedzieć w chroocie, który pokazuje ci legalny moduł FUSE, podczas gdy jądro faktycznie uruchamia jego złowrogą wersję.

Powiedziałbym, że niemożność wykonywania plików niewykonywalnych jest trywialnie ograniczeniem, ponieważ zależy od uprawnień do plików. (Można to obejść za pomocą /lib64/ld-linux-x86-64.so.2 dla pliku, którego nie można wykonać, ale nie pliku na montowaniu bez wykonania)

Istnieje również kwestia obowiązkowych blokad plików, które uniemożliwiają edycję pliku, jeśli plik jest aktualnie używany przez proces, chociaż superużytkownik może go zabić.

W pewnym momencie superużytkownik nie mógł odmontować urządzenia, gdy było ono zajęte, ale można to teraz zrobić za pomocą leniwego umountu.

Inne ograniczenia to:

nie może modyfikować niezmiennych plików i może dołączać tylko do plików tylko do dołączania (linux pozwala superużytkownikowi na usunięcie niezmiennych i dołączanie tylko flag na dowolnym poziomie działania, jednak częściowo pokonując ich cel)

nie może pisać na montowaniu tylko do odczytu ani wykonywać niczego na montowaniu bez wykonania

nie może powiązać niemożliwego do wiązania wierzchowca

nie może ponownie zamontować systemu plików jako do odczytu i zapisu, jeśli jego urządzenie blokowe jest tylko do odczytu

nie może statować niczego na zamontowanym bezpieczniku będącym własnością innego użytkownika, chyba że jest on zamontowany jako allow-other lub allow-root

nie może naruszać ustawień SELinux

celowe ograniczenia właściwe dla samego systemu, które wpływają na rootowanie:

nie można bezpośrednio ustawić czasu c pliku (ani czasu urodzenia, jeśli kiedykolwiek został zaimplementowany)

nie można wyświetlić haseł jako zwykłego tekstu