Czy superużytkownik może zapisywać w plikach tylko do odczytu?

Natknąłem się na zaskakujące (jak dla mnie) zachowanie uprawnień w FreeBSD. Załóżmy, że działam jako użytkownik inny niż root . Tworzę plik, ustawiam jego uprawnienia tylko do odczytu, a następnie próbuję do niego zapisać:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

Na razie w porządku. Teraz robię to samo co root i zapisuje do pliku:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

Czy to błąd lub zamierzone zachowanie? Czy mogę bezpiecznie założyć, że tak będzie działać na każdym Uniksie i Linuksie?

files permissions root

— arrowd
źródło

Każdy użytkownik CAP_DAC_OVERRIDEmoże to zrobić. W prawie wszystkich systemach Linux oznacza to, że root może to zrobić, więc jest to celowe. Nie mogę mówić o części FreeBSD, ale wyobrażam sobie, że mają podobną konfigurację.

— Bratchley,

Powodem, dla którego root musi ZAWSZE mieć możliwość zapisu do pliku, jest to, że w tradycyjnych systemach plików Unix (ext4, zfs itp.) Uprawnienia do pliku są częścią pliku. Więc jeśli root nie może zapisać do pliku, to NIKT nie może ponownie chmodzapisać pliku tylko do odczytu, ponieważ nie może zapisać do pliku.

— slebetman

@slebetman Nie musisz mieć dostępu do zapisu pliku, aby zaktualizować uprawnienia. Po prostu spróbuj touch somefile; chmod 0000 somefile; chmod 0644 somefilejako zwykły użytkownik.

— user253751,

@immibis: To twoje. Root musi mieć możliwość zmiany uprawnień do plików, których nie posiada

— slebetman

@slebetman Tak ... ale mówiłeś o zmianie uprawnień do plików, do których nie możesz pisać, a nie o zmianie uprawnień do plików, których nie posiadasz.

— user253751,

Odpowiedzi:

To normalne, rootże można zastąpić uprawnienia w ten sposób.

Innym przykładem jest rootmożliwość odczytu pliku bez dostępu do odczytu:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

Niektóre systemy mają pojęcie niezmiennych plików. np. na FreeBSD:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

Teraz nawet rootnie można zapisać do pliku. Ale oczywiście rootmożna usunąć flagę:

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

Z FreeBSD możesz pójść o krok dalej i ustawić flagę jądra, aby zapobiec jej rootusunięciu:

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

Teraz nikt, nawet nie rootmoże zmienić tego pliku.

(System wymaga ponownego uruchomienia w celu zmniejszenia poziomu bezpieczeństwa).

— Stephen Harris
źródło

W jaki sposób ponowne uruchomienie wymaga skutecznego zabezpieczenia? Ponadto, jeśli root jest rootem i może coś zrobić, to po co nawet próbować uniemożliwić rootowi robienie tego, czego chce root?

— kot

W bezpiecznym systemie root nie jest podobny do Boga. Poziom bezpieczeństwa FreeBSD to mała próba uczynienia root mniej podobnym do Boga. Securelevel można ustawić domyślnie na 1 w konfiguracji systemu, dzięki czemu pozostaje aktywny nawet po ponownym uruchomieniu. Potrzebowałby więc dostępu do konsoli i trybu pojedynczego użytkownika, co jest bardzo widoczne. Jest cały esej na temat bezpieczeństwa Uniksa, który jest zdecydowanie zbyt duży dla pola komentarza SE, ale staramy się przejść od modelu „root ma dostęp do wszystkich” w coś bardziej szczegółowego. Staramy się egzekwować, gdzie to możliwe (np. Poziom bezpieczeństwa) i wykrywamy gdzie nie (dowody restartu, ścieżki audytu).

— Stephen Harris,

FWIW, w Linuksie chattr +i tstustawia atrybut niezmienny .

— Ruslan

Tak, to bardzo normalne. root nie ma ograniczeń odczytu / zapisu (z bardzo małym wyjątkiem), ponieważ jest rootem.

— Ipor Sircer
źródło