Jak działają uprawnienia do plików dla użytkownika „root”?

Mam następujący plik:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Przełączyłem użytkownika rootna terminal i zauważyłem następujące zachowania:

• Mogę odczytać ten plik i napisać do niego.

• Nie mogę wykonać tego pliku.

• Jeśli ustawię xbit w uprawnieniach użytkownika ( ---x------) lub uprawnieniach grupowych ( ------x---) lub innych uprawnieniach ( ---------x) pliku, będę mógł wykonać ten plik.

Czy ktoś może mi wyjaśnić lub wskazać samouczek, który wyjaśnia wszystkie zasady obowiązujące, gdy rootużytkownik ma do czynienia z plikami i katalogami?

Uprzywilejowany dostęp do plików i katalogów zależy w rzeczywistości od możliwości, a nie tylko od bycia rootlub nie. W praktyce rootzazwyczaj ma wszystkie możliwe możliwości, ale zdarzają się sytuacje, w których wszystkie / wiele z nich można usunąć lub przekazać innym użytkownikom (ich procesom).

W skrócie opisałeś już, jak działają kontrole kontroli dostępu dla procesu uprzywilejowanego. Oto, w jaki sposób wpływają na to różne możliwości:

Główną funkcją jest tutajCAP_DAC_OVERRIDE proces, który może „pomijać odczyt, zapis i wykonywanie pliku i sprawdzanie uprawnień”. Obejmuje to odczytywanie i zapisywanie dowolnych plików, a także czytanie, zapisywanie i uzyskiwanie dostępu do katalogów.

W rzeczywistości nie dotyczy wykonywania plików, które nie są oznaczone jako pliki wykonywalne. Komentarz wgeneric_permission ( fs/namei.c), zanim kontroli dostępu do plików, mówi, że

Przetworniki DAC do odczytu / zapisu są zawsze nadpisywane. Wykonywalne przetworniki cyfrowo-analogowe są nadpisywane, gdy istnieje co najmniej jeden zestaw bitów exec.

A kod sprawdza, czy jest xustawiony przynajmniej jeden bit, jeśli próbujesz wykonać plik. Podejrzewam, że to tylko funkcja wygody, aby zapobiec przypadkowemu uruchomieniu losowych plików danych i otrzymaniu błędów lub dziwnych wyników.

W każdym razie, jeśli możesz zastąpić uprawnienia, możesz po prostu wykonać plik wykonywalny i uruchomić go. _{(Choć teoretycznie może to mieć znaczenie dla plików setuid procesu, można było nadpisywać uprawnienia do plików ( CAP_DAC_OVERRIDE), ale nie ma innych powiązanych funkcji ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Ale CAP_DAC_OVERRIDEpozwala na edycję /etc/shadowi tym podobne, więc jest w przybliżeniu równa i tak po prostu mieć pełny dostęp do roota).}

Istnieje również CAP_DAC_READ_SEARCHmożliwość, która pozwala czytać dowolne pliki i uzyskiwać dostęp do dowolnych katalogów, ale nie można ich uruchamiać ani zapisywać; i CAP_FOWNERto pozwala procesowi robić rzeczy, które zwykle są zarezerwowane tylko dla właściciela pliku, takie jak zmiana bitów uprawnień i grupy plików.

Przesłanianie lepkiego bitu w katalogach jest wymienione tylko poniżej CAP_FOWNER, więc wydaje się, CAP_DAC_OVERRIDEże nie wystarczy to zignorować. (To dałoby ci pozwolenie na pisanie, ale zwykle w lepkich katalogach i tak masz, i +tto ogranicza.)

_{(Myślę, że specjalne urządzenia liczą się tutaj jako „pliki”. Przynajmniej generic_permission()ma tylko kontrolę typu dla katalogów, ale nie sprawdziłem poza tym.)}

Oczywiście nadal istnieją sytuacje, w których nawet możliwości nie pomogą w modyfikacji plików:

• niektóre pliki w /proci /sys, ponieważ tak naprawdę nie są to pliki rzeczywiste
• SELinux i inne moduły bezpieczeństwa, które mogą ograniczać rootowanie
• chattrniezmienne +ii dołączają tylko +aflagi na ext2 / ext3 / ext4, które zatrzymują nawet rootowanie i zapobiegają również zmianie nazw plików itp.
• sieciowe systemy plików, w których serwer może wykonywać własną kontrolę dostępu, np. root_squashw NFS mapuje root na nikogo
• BEZPIECZNIK, który, jak zakładam, mógłby zrobić wszystko
• wierzchowce tylko do odczytu
• urządzenia tylko do odczytu

Dokładnie tak, jak zauważyłeś dla domyślnych uprawnień:

• Odczyt i zapis:
  Domyślnie użytkownik root może uzyskać dostęp do dowolnego pliku w systemie. Możesz usunąć ten dostęp, zmieniając atrybuty, np. Wyjaśnij tutaj: chattr . Jest to następnie powiązane z możliwościami.

• Wykonaj:
  użytkownik root nie ma uprawnień do wykonywania, chyba że ustawiony jest co najmniej jeden z bitów wykonania.

myFile.txtOtrzymuje się chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- oznacza, że ​​nie ma uprawnień dla użytkownika, grupy i innych.

Użytkownik root ma nieograniczoną możliwość modyfikowania tego pliku. Odczyt / zapis został przyznany. Aby wykonać ten plik, użytkownik root musi i tak ustawić go na wykonanie. (chmod 100, 010 lub 001)

Tryb wykonywania jest traktowany nieco inaczej niż inne tryby.

Uprawnienia do odczytu i zapisu służą do egzekwowania zasad bezpieczeństwa. rootUżytkownik jest na ogół wolny od ograniczeń bezpieczeństwa (są pewne wyjątki, takie jak pliki niezmiennych i nowoczesne funkcje, takie jak funkcje dokonały tym bardziej drobnoziarnisty), dlatego inna nazwa tego konta jest „superuser”.

Uprawnienie do wykonywania jest raczej trybem doradczym, pozwalającym odróżnić, czy plik ma być wykonywalny, czy tylko dane. Z tego powodu nawet użytkownik root jest tego posłuszny - nie ma sensu wykonywać pliku danych. Jeśli żadne z uprawnień do wykonywania nie jest ustawione, root nie może wykonać pliku; jeśli któryś z nich jest ustawiony, może to zrobić. Oczywiście, ponieważ root ma również uprawnienia do zmiany uprawnień do dowolnego pliku, konto może uczynić plik wykonywalnym, jeśli chce (chyba że system plików jest tylko do odczytu).

BTW, skrypty są w tym interesującym przypadkiem. Skrypty to pliki danych dla odpowiedniego tłumacza. Jeśli skrypt ma #!wiersz, możesz go wykonać jako program - interpreter nazwany w shebang jest uruchamiany z nazwą pliku skryptu jako argumentem. Ale będzie to możliwe tylko po ustawieniu uprawnienia do wykonywania. Z drugiej strony możesz po prostu uruchomić interpretera bezpośrednio, np /bin/bash scriptname. Tłumacze dbają tylko o to, czy potrafią odczytać plik, nie sprawdzają uprawnień do wykonywania.

Pozwól, że ci wyjaśnię teoretycznie.

użytkownik root jest królem systemu operacyjnego.

Jeśli plik lub katalog ma jakieś uprawnienia, takie jak X, do wykonania, ale nic innego, a ktoś taki jak użytkownik Steve posiada ten plik, to root może go również wykonać.

Zawsze pamiętaj, że w systemie Linux root może zrobić wszystko, nie ma żadnych ograniczeń dotyczących rootowania.