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

23

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

Kolyunya
źródło
2
„Przywilej” lub „pozwolenie” to prawo do zrobienia czegoś, prawo, które można przyznać określonym kontom użytkowników. W systemach UNIX i Linux (z wyjątkiem wersji hartowanych, takich jak SELinux), root ma wszelkie prawa. Nie ma prawa, które może zostać przyznane root, a zatem nie można odebrać żadnego prawa root.
MSalters
1
@MSalters, ułaskawienie? Z pewnością można zachować UID 0, wciąż odwołując możliwości procesu.
Charles Duffy,
... ustawiony SECBIT_NOROOT, a bycie uid 0 nie daje już automatycznie jednej możliwości.
Charles Duffy,
Tak wiele odpowiedzi - czy warto zamienić to w wiki społeczności, czy może ktoś powinien napisać odpowiedź podsumowującą?
Simon Richter
1
@ SimonRichter Będę także jako George, aby powiedzieć nam, co miał na myśli w swoim wykładzie.
Kolyunya,

Odpowiedzi:

24

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.

Archemar
źródło
Przypadek 1 jest zasadniczo błędem, ponieważ jesteś tylko rootlokalnie, niekoniecznie w innych systemach. Przypadki 2 i 3 nie są uprawnieniami (nie można ich nikomu przyznać). Więc +1, twoje pierwsze zdanie wydaje się poprawne.
MSalters
Technicznie rzecz biorąc, rootna komputerze lokalnym można robić wszystko, co się chce, z takim samym przywilejem jak użytkownik lokalny, su - usernamejeśli nic innego. Nigdy nie jestem pewien, dlaczego nie zadawali sobie trudu, aby rootnie móc pisać takich udziałów sieciowych; wydaje się to raczej bezcelowe.
Tom Hunt
4
To odwieczne pytanie „Czy roothasło może utworzyć nawet on nie może uzyskać dostępu?”
corsiKa,
5
@TomHunt, jednym z powodów, dla których nie należy udzielać rootdostępu do udziałów NFS, jest zapobieganie tworzeniu plików binarnych „suid root” na zdalnym serwerze, co można wykorzystać w celu uzyskania pełnego zdalnego dostępu do serwera.
Mark
1
Zabicie procesu w nieprzerwanym oczekiwaniu nie wydaje mi się prawem . To coś, czego po prostu nie możesz zrobić. Jak pisanie do pełnego systemu plików.
Blacklight Shining
11

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)

Jan
źródło
1
Dziękuję za odpowiedź, John! Ale wyraźnie stwierdził, że to pytanie nie dotyczy SELinuksa ...
Kolyunya,
Następnie, z pominięciem dalszych szczegółów, będę musiał uznać za fałszywe stwierdzenie, że root nie ma dostępu do niektórych funkcji. (Nie uważam, aby system operacyjny był zablokowany w BIOS-ie lub podobnie przez zabezpieczenia BIOS-u.)
John
Masz również komplikację, że root kontroluje konfigurację SELinux. Jeśli (jako root) jestem zablokowany w akcji, mogę zmodyfikować SELinux, aby zezwolić na akcję, a następnie zmienić ją później. Może się to wydostać w zależności od miejsca przechowywania śladu kłody.
doneal24,
2
Niekoniecznie prawda. Zabierz CAP_NET_ADMIN, a bycie identyfikatorem UID 0 wciąż nie pozwala procesowi zmienić konfiguracji sieci. (Podobnie w przypadku CAP_SYS_ADMIN i umiejętności, które kontroluje itp.).
Charles Duffy,
5

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.
Siguza
źródło
1
W rzeczywistości można uruchomić plik wykonywalny bez zestawu bitów wykonania: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hellodaje oczekiwany Hello, World!wynik,
doneal24
@ DougO'Neal Ale czy zatem nie jest /lib64/ld-linux-x86-64.so.2to plik wykonywalny, a ./hellotylko argument? Bo to jak przekazywanie pliku tekstowego zawierającego kod PHP do interpretera PHP ... lub uruchamianie skryptu bash przy użyciu bash ./my_script...
Siguza
1
@ DougO'Neal To działało, ale zostało wyłączone w najnowszych wersjach glibc (aby nie było trywialnym obejściem montowań noexec).
duskwuff
@duskwuff Jak najnowsza wersja glibc? To nadal działa w systemie Ubuntu 14.04.
doneal24
1
Apple nie dodało go do ln, ale klasa systemowa, której używa ln, np. Link, pozwala na to patrz stackoverflow.com/a/4707231/151019 Tak działa Time Machine
użytkownik151019
4

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
Dmitrij Grigoriew
źródło
... ale proces UID-0 może utracić zdolność do ładowania nowych modułów jądra (lub ich szybkiego łączenia /proc/kmem) poprzez odwołanie możliwości.
Charles Duffy,
4

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’
Tuomas
źródło
Jądro Linux nie prawidłowo wdrożyć BSD SecureLevel siłownia (już), co daje malejących przychodów na niezmienne i dołączania tylko atrybuty. W przypadku poziomu bezpiecznego nie można zresetować tych bitów, gdy system znajduje się na poziomie uruchamiania dla wielu użytkowników, więc administrator musiałby się zamknąć i użyć lokalnej konsoli, która zatrzymałaby atakujących z sieci.
Simon Richter
2

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.

Vinz
źródło
1

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

sleblanc
źródło
0

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

inny facet
źródło