Какие права доступа не может нарушать суперпользователь?

Fr. Br. Джордж рассказал в одной из своих лекций (на русском языке), что есть некоторые права доступа, которые суперпользователь не может нарушить. То есть есть какое-то право доступа, которое может запретить суперпользователю что-либо делать.

Я не смог найти эту информацию в Интернете, и мне любопытно, что это. Возможно, это связано с выполнением ядра системы, не так ли? Может он не может остановить некоторые системные процессы? А может он не может запустить процесс в реальном режиме?

Этот вопрос не имеет отношения к SELinux (Джордж говорил об этом прямо перед вопросом).

Доступ запрещен для root :

rootможет быть отказано в прямом доступе к сети. Это полезно на интернет подключен хостов, так как она требует , чтобы вы войти в систему как smith, то sudo.

некоторые вещи, которые root не может сделать :

Это НЕ из-за отсутствия привилегий. Я не вижу ничего, что root не может сделать, однако некоторые технические проблемы могут восприниматься как «запрещенные».

Я root, почему я не могу создать / удалить этот файл, в то время как обычный пользователь может?

Вы находитесь на общем ресурсе NFS / samba, и у вас нет конкретной ( access=) авторизации. Обычный пользователь не соблюдает общее право. (см. локальный и удаленный корень ниже)

Я root, почему я не могу убить этот процесс?

Имеется ожидающий ввод-вывод и физический диск / удаленный LUN были отключены, процесс может быть остановлен только перезагрузкой.

Я root, как мне получить пароль от archemar?

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

локальный против удаленного корня

• Вы можете иметь права root на своей станции / ПК и использовать общий ресурс NFS компании / колледжа / университета / провайдера.
• Далее вы можете иметь только учетную запись без полномочий root на компьютере, экспортирующем NFS.

В настоящее время

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

просто войдите на сервер NFS, запустите, ./bashи вы получите права root на сервере компании / университета.

В обычном случае это неверно - у суперпользователя есть привилегии / разрешения на любые функции, которые предоставляет система (1). Это правило нарушается, когда вы добавляете SELinux в микс. С SELinux можно ограничить даже привилегии root, чтобы запретить определенные действия. Однако определенные запрещенные действия сильно зависят от конфигурации SELinux на локальной машине, поэтому даже в случае SELinux на этот вопрос нельзя ответить в общем смысле.

(1) - если система не предоставляет заданную функцию, например, отсутствует функциональность ядра в реальном времени, то я считаю утверждение «root не имеет доступа к этой функции» ложным, поскольку это утверждение опирается на ложное предположение (а именно, что данная функция доступна любому в этой системе)

С одной стороны, есть вещи, которые ни один пользователь не может сделать, такие как

• жестко связанные каталоги (из-за ограничений файловой системы)
• запись на уже сожженный CD-ROM (потому что физика)

Но это не привилегии, потому что они не могут быть предоставлены, они просто невозможны ни для кого.

Кроме того, существуют ограничения для всей системы или ее частей, которые можно включать или выключать.
Например, в OS X есть опция, позволяющая запускать код, только если он был подписан Apple.

Я также не считаю это действительной привилегией, потому что ни один пользователь не может иметь ее, если суперпользователь не может. Вы можете только глобально отключить его.

Изменить:
Ваша идея файла без исполняемого бита также попадет в эту категорию, так как буквально никто не может сделать это, и никто не может получить это разрешение.
И даже если другой пользователь или группа получит разрешение на выполнение этого файла, но не root, а корневая группа пользователей не находится, root все равно сможет выполнить этот файл (протестировано на OS X 10.10, 10.11 и сервере Ubuntu 15.04).

Помимо этих случаев, root ничего не может сделать.
Однако существует функция, называемая режимом ядра (в отличие от режима пользователя).

Насколько я знаю, в нормальной системе только ядро, расширения ядра и драйверы работают в режиме ядра, а все остальное (включая оболочку, из которой вы входите в систему как root) работает в режиме пользователя.
Таким образом, вы можете утверждать, что «недостаточно быть корнем». Однако в большинстве систем пользователь root может загружать модули ядра, которые, в свою очередь, будут работать в режиме ядра, эффективно предоставляя root способ запуска кода в режиме ядра.

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

На OS X, начиная с версии 10.11 (El Capitan), существует также так называемый «режим без root» (хотя название вводит в заблуждение, потому что root все еще существует), что эффективно запрещает некоторые действия 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что делает файл непреложных даже для корня. Например:

# 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, может установить или очистить этот атрибут.

Хотя root может легко отменить неизменность:

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

На FreeBSD вы не можете использовать gmirrorуже смонтированный раздел, даже с правами root:

Метка gmirror -v -b предпочитает gm0s1 ad4s1
gmirror: Невозможно сохранить метаданные в ad4s1: Операция не разрешена.

Вы должны установить sysctl( kern.geom.debugflags=16), чтобы иметь возможность сделать это.

rootявляется привилегированным пользователем, но эти права предоставляются ядром. Так что ядро ​​имеет больше привилегий, чем root.

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

Это не мешает пользователю root отключить эту опцию или заменить модуль FUSE на модуль, который молча отбрасывает опцию, если вы не сделаете файловую систему доступной только для чтения. Однако это приводит только к ситуации «кто следит за сторожами»: как вы можете проверить, что система не врет? Ваша оболочка может даже находиться в chroot, который показывает вам легитимный модуль FUSE, в то время как ядро ​​фактически использует его вредоносную версию.

Я бы сказал, что невозможность выполнять неисполняемые файлы - тривиальное ограничение, поскольку оно зависит от прав доступа к файлам. (Можно обойти это, используя /lib64/ld-linux-x86-64.so.2 для неисполнимого файла, но не для файла при монтировании без exec)

Существует также проблема обязательных блокировок файлов, которые предотвращают редактирование файлов, если файл в данный момент используется процессом, хотя суперпользователь может уничтожить процесс.

В какой-то момент суперпользователь не смог размонтировать устройство, когда оно было занято, но теперь это можно сделать с помощью отложенного размонтирования.

Другие ограничения:

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

не может записать в монтируемое только для чтения монтирование или выполнить что-либо в монтировании без exec

не может связать несвязываемое крепление

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

не может статировать что-либо на монтируемом предохранителе, принадлежащем другому пользователю, если не смонтировано allow-other или allow-root

не может нарушить настройки SELinux

Преднамеренные ограничения, присущие самой системе, которые влияют на root:

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

не может просматривать пароли в виде простого текста