Чи може супер користувач писати у файли лише для читання?

Я натрапив на дивовижну (для мене) поведінку дозволу на FreeBSD. Скажімо, я працюю як некореневий користувач. Я створюю файл, встановлюю його дозвіл на режим лише для читання, а потім намагаюся записати в нього:

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

Все йде нормально. Тепер я роблю те саме, що і root, і він записує у файл:

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

Це помилка чи передбачувана поведінка? Чи можна з упевненістю припустити, що це діятиме так на будь-якому Unix & Linux?

files permissions root

— стрілка
джерело

Будь-який користувач CAP_DAC_OVERRIDEможе зробити це. Майже на всіх системах Linux це означає, що root може це зробити, тому це навмисно. Не можу говорити за частину FreeBSD, але я б уявив, що вони мають подібний параметр.

— Братчлі

Причина кореня ВЖЕ бути здатною записувати у файл, тому що в традиційних файлових системах unix (ext4, zfs тощо) дозволи файлу є частиною файлу. Отже, якщо root не може записати у файл, NOBODY може знову зробити файл, доступним лише для читання, оскільки він chmodне може записати у файл.

— slebetman

@slebetman Вам не потрібно мати доступ до запису до файлу, щоб оновити дозволи. Просто спробуйте touch somefile; chmod 0000 somefile; chmod 0644 somefileяк звичайний користувач.

— користувач253751

@immibis: Це ти є власником. Корінь повинен мати можливість змінювати дозволи на файли, якими він не володіє

— slebetman

@slebetman Так ... але ви говорили про зміну дозволів на файли, на які ви не можете записати, а також про зміну дозволів на файл, яким ви не володієте.

— користувач253751

Відповіді:

Це нормально, щоб rootтаким чином можна було змінити дозволи.

Ще один приклад - rootможливість читати файл без доступу для читання:

$ 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

Деякі системи мають поняття незмінних файлів. наприклад, на 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.

Зараз навіть rootне вдається записати у файл. Але, звичайно, rootможна зняти прапор:

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

За допомогою FreeBSD ви можете піти на крок далі і встановити прапор ядра, щоб запобігти rootвидаленню прапора:

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

Тепер ніхто, навіть не rootможе змінити цей файл.

(Системі потрібна перезавантаження для зменшення рівня безпеки).

— Стівен Харріс
джерело

Як потрібно перезавантажити ефективний захід безпеки? Крім того, якщо корінь є корінним і може зробити що завгодно, навіщо навіть турбуватися, намагаючись запобігти виконанню кореня тим, що він хоче?

— кіт

У захищеній системі корінь не схожий на Бога. FreeBSD securelevel - це невелика спроба зробити корінь менш схожим на Бога. У налаштуваннях системи Securelevel можна встановити значення 1 за замовчуванням, щоб він залишався активним навіть після перезавантаження. Тоді йому знадобиться доступ до консолі та єдиний користувальницький режим, і це дуже очевидно. Є цілий нарис навколо безпеки Unix, що занадто багато для поля коментарів SE, але ми намагаємось перейти від моделі "root has all access" у щось більш нюансове. Ми намагаємось застосувати, де це можливо (наприклад, безпечний рівень) та виявити, де ні (перезавантажте докази, аудиторські траси).

— Стівен Гарріс

FWIW, в Linux chattr +i tstвстановлює незмінний атрибут.

— Руслан

Так, це дуже нормально. root не має обмежень на читання / запис (за дуже невеликим винятком), тому що він є коренем.

— Іпор Сірсер
джерело