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

23

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

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

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

Колюня
источник
2
«Привилегия» или «разрешение» - это право на что-то, право, которое может быть предоставлено определенным учетным записям пользователей. В UNIX и Linux (за исключением защищенных версий, таких как SELinux), root имеет все права. Там нет права, которое может быть предоставлено root, и, следовательно, нет права, которое можно отнять root.
MSalters
1
@MSalters, простите? Можно, конечно, сохранить UID 0, все еще отменяя возможности процесса.
Чарльз Даффи
... установлен SECBIT_NOROOT, и будучи uid 0 больше не дает одну способность автоматически.
Чарльз Даффи
Так много ответов - имеет ли смысл превращать это в вики сообщества, или кто-то должен написать краткий ответ?
Саймон Рихтер
1
@SimonRichter Я также собираюсь, как Джордж, рассказать нам, что он имел в виду в своей лекции.
Колюня

Ответы:

24

Доступ запрещен для 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 на сервере компании / университета.

Archemar
источник
Случай 1 в основном является ошибкой, потому что вы находитесь только rootлокально, не обязательно в других системах. Варианты 2 и 3 не являются привилегиями (они не могут быть предоставлены никому). +1, ваше первое предложение кажется правильным.
MSalters
Технически, rootна локальной машине можно делать все, что угодно, с теми же привилегиями, что и локальный пользователь, su - usernameесли не больше. Я никогда не могу понять, почему они rootне могли писать подобные сетевые ресурсы; это кажется довольно бессмысленным.
Том Хант
4
Это старый вопрос "Может ли rootсоздать пароль, даже если он не может получить доступ?"
CorsiKa
5
@ TomHunt, одна из причин, по которой не предоставляется rootдоступ к общим ресурсам NFS, заключается в том, чтобы предотвратить создание двоичных файлов «suid root» на удаленном сервере, что можно использовать для полного удаленного доступа к серверу.
Марк
1
Убивать процесс в непрерывном ожидании не кажется мне правильным . Это то, что вы просто не можете сделать. Как запись в полную файловую систему.
Blacklight Shining
11

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

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

Джон
источник
1
Спасибо за ответ, Джон! Но он недвусмысленно заявил, что этот вопрос не имеет отношения к SELinux ...
Колюня
Затем, за исключением дальнейших подробностей, мне нужно будет считать ложным утверждение о том, что root не имеет доступа к определенным функциям. (Я не рассматриваю случай, когда ОС была заблокирована в BIOS или аналогичной системой из-за безопасности BIOS.)
John
У вас также есть сложность в том, что root контролирует конфигурацию SELinux. Если я (как root) заблокирован в действии, я могу изменить SELinux, чтобы разрешить действие, а затем изменить его обратно. Может сойти с рук, в зависимости от того, где хранится журнал.
doneal24
2
Не обязательно правда. Уберите его CAP_NET_ADMIN, а значение uid 0 все еще не позволяет процессу изменять конфигурацию сети. (Аналогично для CAP_SYS_ADMIN и способностей, которыми он управляет, и т. Д.).
Чарльз Даффи
5

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

  • жестко связанные каталоги (из-за ограничений файловой системы)
  • запись на уже сожженный 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.
Siguza
источник
1
На самом деле, вы можете запустить исполняемый файл без установленных битов выполнения: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloвыдает ожидаемый Hello, World!результат,
doneal24
@ DougO'Neal Но разве не /lib64/ld-linux-x86-64.so.2фактический исполняемый файл, а ./helloпросто аргумент? Потому что это похоже на передачу текстового файла, содержащего код PHP, интерпретатору PHP ... или как запуск сценария bash с использованием bash ./my_script...
Siguza
1
@ DougO'Neal Раньше это работало, но было отключено в последних версиях glibc (чтобы не допустить тривиального обхода монтирования noexec).
сумерки
@duskwuff Насколько свежа версия glibc? Это все еще работает под Ubuntu 14.04.
doneal24
1
Apple не добавила его в ln, но системный класс, который использует ln, например, link, разрешает это, см. Stackoverflow.com/a/4707231/151019 Так работает Time Machine
user151019
4

Упомянутое вами «ядро системы» хорошо rootконтролируется, например, с помощью загружаемых модулей ядра. Конечно, это предполагает, что загрузка модулей ядра поддерживается ядром, никто не может выполнять действия, которые даже неосуществимы root.

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

Наконец, реальный режим: ядро ​​Linux не поддерживает его, поэтому, опять же, никто не может сделать невозможное, даже root.

@Siguza упомянул выполнение файлов без xразрешения, что вполне возможно для rootпользователя:

/lib/ld-linux.so.2 /path/to/executable
Дмитрий Григорьев
источник
... но процесс uid-0 может потерять способность загружать новые модули ядра (или выполнять их горячее исправление /proc/kmem) через отзыв возможности.
Чарльз Даффи
4

Одним из примеров может быть изменение неизменного файла: Вы можете установить атрибут файла 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’
Туомас
источник
Linux ядро не правильно реализовать BSD защиты системы объекта ( в малейшей), что дает вам убывающую отдачу от неизменны и Append только атрибуты. С уровнем безопасности эти биты не могут быть сброшены, когда система находится на многопользовательском уровне выполнения, поэтому администратору придется завершить работу и использовать локальную консоль, которая остановит сетевых атакующих.
Саймон Рихтер
2

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

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

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

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

Vinz
источник
1

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

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

sleblanc
источник
0

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

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

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

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

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

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

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

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

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

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

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

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

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

другой парень
источник