Які права доступу не може порушувати користувач?

О. Бр. Джордж сказав в одній зі своїх лекцій (це російською мовою), що є деякі права доступу, які суперпользователь не може порушити. Тобто є деякі права доступу, які можуть заборонити суперпользователю щось робити.

Мені не вдалося знайти цю інформацію в Інтернеті і мені цікаво, що вони є. Це, мабуть, щось, пов’язане з виконанням основної системи, чи не так? Може, він не може зупинити деякі системні процеси? А може він не може запустити процес у реальному режимі?

Це питання не пов'язане з SELinux (Джордж говорив про це прямо перед питанням).

доступ до root відмовлено :

rootможна відмовити у прямому доступу до мережі. Це корисно для хостів, підключених до Інтернету, оскільки це вимагає, щоб ви увійшли як smithтоді sudo.

деякі речі root не можуть зробити :

Це НЕ через відсутність привілеїв. Я не бачу нічого кореневого, що не міг зробити, проте деякі технічні проблеми можуть сприйматися як "заборонені".

Я root, чому я не можу створити / видалити цей файл, а звичайний користувач може?

Ви перебуваєте на NFS / самбі, і вам не дали конкретного ( access=) дозволу. Звичайний користувач не дотримується загального права. (див. локальний vs віддалений корінь нижче)

Я корінь, чому я не можу вбити цей процес?

Існує відключений введення / вивід, а фізичний привід / віддалений LUN були відключені, процес може бути знищений лише за допомогою перезавантаження.

Я root, як я можу отримати пароль архемара?

Ви можете su - archemarвсе правильно або змінити пароль архемара, не знаючи попереднього, але ви не можете його прочитати (за винятком ключа реєстратора), оскільки паролі зберігаються за допомогою однобічного хеша.

локальний vs віддалений корінь

• Ви можете отримати корінний зв'язок на своїй станції / ПК та користуватися NFS акцією компанії / коледжу / університету / постачальника.
• Далі ви можете мати лише некореневий логін для комп'ютера, який експортує NFS.

Тепер

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

просто увійдіть на сервер NFS, запустіть ./bashі ви корінь на сервері компанії / університету.

У звичайному випадку це неправильно - суперкомп'ютер має привілеї / дозволи на будь-яку функціональність, яку надає система (1). Там, де це правило порушується, це коли ви кидаєте SELinux у суміш. За допомогою SELinux можна обмежити навіть привілеї root, щоб заборонити певні дії. Однак, заборонені конкретні дії сильно залежать від конфігурації SELinux локальної машини, тому навіть із SELinux на це питання не можна відповісти в загальному сенсі.

(1) - якщо система не надає задану функцію, наприклад, функціональність ядра в реальному часі відсутня, я вважаю вислів "root не має доступу до цієї функціональності" як помилковий, оскільки цей оператор покладається на помилкове припущення (а саме те, що дана функція доступна кожному в цій системі)

З одного боку, є речі, які не може зробити жоден користувач , наприклад

• жорсткі посилання каталогів (через обмеження файлової системи)
• запис на вже згорілий компакт-диск (бо фізика)

Але це не привілеї, тому що їх не можна надати, вони просто неможливі нікому.

Тоді існують обмеження для всієї системи або її частин, які можна вмикати або вимикати.
Наприклад, в OS X є можливість дозволити запуск коду, лише якщо він був підписаний Apple.

Я не вважаю це фактичним привілеєм, тому що жоден користувач не може його мати, якщо суперпользователь не може. Відключити його можна лише глобально.

Редагувати:
Ваша ідея файлу без виконуваного біта також потраплятиме до цієї категорії, оскільки буквально ніхто цього не може зробити, і ніхто не може надати цей дозвіл.
І навіть якщо надавати іншому користувачеві чи групі дозвіл на виконання цього файлу, але не root або корінь групи користувачів, корінь все одно зможе виконати цей файл (протестовано на серверах OS X 10.10, 10.11 та Ubuntu 15.04).

Крім цих випадків, корінь ледь нічого не може зробити.
Однак існує річ, яка називається режимом ядра (на відміну від режиму користувача).

Наскільки я знаю, у здоровій системі лише ядро, розширення ядра та драйвери працюють у режимі ядра, а все інше (включаючи оболонку, з якої ви входите як root) працює в режимі користувача.
Ви можете, таким чином, стверджувати, що "бути коренем недостатньо". Однак у більшості систем користувач root може завантажувати модулі ядра, які, в свою чергу, працюватимуть у режимі ядра, ефективно надаючи root способу запуску коду в режимі ядра.

Однак існують системи (як iOS), де це неможливо (як завгодно) неможливо, принаймні не без використання цілих мереж безпеки. Здебільшого це пов'язано з підвищеною безпекою, як, наприклад, виконання підпису коду.
Наприклад, є ключі шифрування AES, вбудовані в процесори iDevices, до яких можна отримати доступ лише в режимі ядра. Моделі ядра можуть отримати доступ до них, але код у цих модулях ядра також повинен бути підписаний Apple, щоб ядро ​​прийняло їх.

В OS X, починаючи з версії 10.11 (El Capitan), існує також так званий "безкорисний режим" (хоча назва вводить в оману, оскільки root все ще існує), що ефективно забороняє викорінювати певні речі, які інсталятори все ще можуть робити.
Цитуючи цю чудову відповідь на AskDifferent :

Ось що це обмежує навіть від root:

• Ви нічого не можете змінювати в / System, / bin, / sbin або / usr (крім / usr / local); або будь-який із вбудованих додатків та утиліт. Лише оновлення програмного забезпечення та програмного забезпечення можуть змінювати ці області, і навіть вони роблять це лише під час встановлення пакетів, підписаних Apple.

Згадане вами "виконання ядра системи" знаходиться під rootконтролем, наприклад, через завантажувані модулі ядра. Звичайно, це передбачає, що завантаження модулів ядра підтримується ядром, ніхто не може виконувати навіть такі дії, які неможливо root.

Те саме стосується системних процесів. rootдозволяється вбивати будь-який процес, але неможливо зупинити процес, що працює в режимі ядра, не порушуючи цілісність ядра, тому просто неможливо негайно зупинити такий оброблений процес. Зауважте, що rootне буде заборонено вбивати ці процеси, вбивство саме по собі просто не матиме ефекту.

Нарешті, реальний режим: Linux ядро ​​не підтримує його, тому, знову ж таки, ніхто не може зробити навіть незручне root.

@Siguza згадав про виконання файлів без xдозволу, що цілком можливо для rootкористувача:

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

Одним із прикладів може бути зміна незмінного файлу: Ви можете встановити атрибут файлу, iзавдяки chattrякому файл буде непорушним навіть для root. Наприклад:

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

Зауважте, що файл у ls -lвихідному файлі виглядає як звичайний файл для запису :

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

Щоб побачити iатрибут, ви повинні використовувати lsattr:

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

Сторінка керівництва chattr повідомляє про iатрибут:

Файл з атрибутом `i 'неможливо змінити: його неможливо видалити чи перейменувати, не можна створити посилання на цей файл і не можна записати дані у файл. Лише суперпользователь або процес, що має можливість CAP_LINUX_IMMUTABLE, може встановити або очистити цей атрибут.

Хоча корінь може легко скасувати незмінність:

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

У FreeBSD ви не можете використовувати gmirrorвже встановлений розділ, навіть як root:

gmirror label -v -b віддає перевагу gm0s1 ad4s1
gmirror: Неможливо зберегти метадані на ad4s1: Операція заборонена.

Ви повинні встановити sysctl( kern.geom.debugflags=16), щоб мати можливість це зробити.

rootє привілейованим користувачем, але ці права надає ядро. Тож ядро ​​отримало більше привілеїв, ніж root.

Якщо припустити співпрацю з самим кореневим користувачем, rootможна не допустити доступу до монтажу FUSE (з параметрами allow_otherабо allow_root), але це тому, що FUSE був розроблений таким чином. Оскільки FUSE знаходиться на віртуальному шарі, він може повертати будь-яку вподобану йому помилку на основі логіки, на відміну від звичайних блокових модулів пристроїв, які прагнуть бути максимально прозорими і тонкими, делегуючи дозволи на інший рівень.

Це не заважає кореневому користувачеві відключити цю опцію або замінити модуль FUSE таким, який мовчки відкидає цю опцію, якщо тільки ви не зробите файлову систему лише для читання. Однак це призводить лише до ситуації "хто спостерігає за сторожами": як можна перевірити, що система не бреше? Ваша оболонка може навіть сидіти в chroot, який показує вам законний модуль FUSE, тоді як ядро ​​насправді працює зловмисною версією.

Я б сказав, що неможливість виконання невиконаних файлів є тривіальним обмеженням, оскільки це залежить від дозволів файлів. (Можна обійти це за допомогою /lib64/ld-linux-x86-64.so.2 для невиконаного файлу, але не для файлу на no-exec-кріпленні)

Існує також проблема обов'язкових блокувань файлів, які перешкоджають редагуванню файлів, якщо файл в даний час використовується процесом, хоча суперкористувач може вбити процес.

Одного разу, суперкористувач не міг відключити пристрій, поки пристрій зайнятий, але це зараз можна зробити за допомогою ледачого вмісту.

Інші обмеження:

не може змінювати незмінні файли і може додавати лише до файлів, що додаються (linux дозволяє суперкористувачеві видаляти незмінні та додавати лише прапори на будь-якому рівні запуску, проте частково перемагаючи призначення їх)

не може записувати на кріплення, доступне лише для читання, або виконувати що-небудь на моніторі no-exec

не може прив’язати незгорнуте кріплення

не може відновити файлову систему як читання-запис, якщо її блоковий пристрій доступний лише для читання

не може нічого статувати на кріпленні запобіжника, який належить іншому користувачеві, якщо тільки він не встановлений дозволено-інше або дозволити-root

не може порушити налаштування SELinux

навмисні обмеження, притаманні самій системі, які впливають на корінь:

не може безпосередньо встановити c-час файлу (або час народження, якщо він коли-небудь реалізований)

не може переглядати паролі як звичайний текст