Fr. Br. Джордж рассказал в одной из своих лекций (на русском языке), что есть некоторые права доступа, которые суперпользователь не может нарушить. То есть есть какое-то право доступа, которое может запретить суперпользователю что-либо делать.
Я не смог найти эту информацию в Интернете, и мне любопытно, что это. Возможно, это связано с выполнением ядра системы, не так ли? Может он не может остановить некоторые системные процессы? А может он не может запустить процесс в реальном режиме?
Этот вопрос не имеет отношения к SELinux (Джордж говорил об этом прямо перед вопросом).
root
privileges
access-control
Колюня
источник
источник
root
, и, следовательно, нет права, которое можно отнятьroot
.SECBIT_NOROOT
, и будучи uid 0 больше не дает одну способность автоматически.Ответы:
Доступ запрещен для root :
root
может быть отказано в прямом доступе к сети. Это полезно на интернет подключен хостов, так как она требует , чтобы вы войти в систему какsmith
, тоsudo
.некоторые вещи, которые root не может сделать :
Это НЕ из-за отсутствия привилегий. Я не вижу ничего, что root не может сделать, однако некоторые технические проблемы могут восприниматься как «запрещенные».
Вы находитесь на общем ресурсе NFS / samba, и у вас нет конкретной (
access=
) авторизации. Обычный пользователь не соблюдает общее право. (см. локальный и удаленный корень ниже)Имеется ожидающий ввод-вывод и физический диск / удаленный LUN были отключены, процесс может быть остановлен только перезагрузкой.
Вы можете сделать
su - archemar
все правильно или изменить пароль archemar, не зная предыдущего, но вы не можете его прочитать (если не считать регистратор ключей), поскольку пароли хранятся с использованием одностороннего хэша.локальный против удаленного корня
В настоящее время
просто войдите на сервер NFS, запустите,
./bash
и вы получите права root на сервере компании / университета.источник
root
локально, не обязательно в других системах. Варианты 2 и 3 не являются привилегиями (они не могут быть предоставлены никому). +1, ваше первое предложение кажется правильным.root
на локальной машине можно делать все, что угодно, с теми же привилегиями, что и локальный пользователь,su - username
если не больше. Я никогда не могу понять, почему ониroot
не могли писать подобные сетевые ресурсы; это кажется довольно бессмысленным.root
создать пароль, даже если он не может получить доступ?"root
доступ к общим ресурсам NFS, заключается в том, чтобы предотвратить создание двоичных файлов «suid root» на удаленном сервере, что можно использовать для полного удаленного доступа к серверу.В обычном случае это неверно - у суперпользователя есть привилегии / разрешения на любые функции, которые предоставляет система (1). Это правило нарушается, когда вы добавляете SELinux в микс. С SELinux можно ограничить даже привилегии root, чтобы запретить определенные действия. Однако определенные запрещенные действия сильно зависят от конфигурации SELinux на локальной машине, поэтому даже в случае SELinux на этот вопрос нельзя ответить в общем смысле.
(1) - если система не предоставляет заданную функцию, например, отсутствует функциональность ядра в реальном времени, то я считаю утверждение «root не имеет доступа к этой функции» ложным, поскольку это утверждение опирается на ложное предположение (а именно, что данная функция доступна любому в этой системе)
источник
С одной стороны, есть вещи, которые ни один пользователь не может сделать, такие как
Но это не привилегии, потому что они не могут быть предоставлены, они просто невозможны ни для кого.
Кроме того, существуют ограничения для всей системы или ее частей, которые можно включать или выключать.
Например, в 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 :
источник
gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hello
выдает ожидаемыйHello, World!
результат,/lib64/ld-linux-x86-64.so.2
фактический исполняемый файл, а./hello
просто аргумент? Потому что это похоже на передачу текстового файла, содержащего код PHP, интерпретатору PHP ... или как запуск сценария bash с использованиемbash ./my_script
...Упомянутое вами «ядро системы» хорошо
root
контролируется, например, с помощью загружаемых модулей ядра. Конечно, это предполагает, что загрузка модулей ядра поддерживается ядром, никто не может выполнять действия, которые даже неосуществимыroot
.То же самое относится и к системным процессам.
root
разрешено уничтожать любой процесс, но невозможно остановить процесс, работающий в режиме ядра, не ставя под угрозу целостность ядра, поэтому просто невозможно немедленно остановить такой процесс. Обратите внимание, чтоroot
не будет отказано в уничтожении этих процессов, само по себе уничтожение не будет иметь никакого эффекта.Наконец, реальный режим: ядро Linux не поддерживает его, поэтому, опять же, никто не может сделать невозможное, даже
root
.@Siguza упомянул выполнение файлов без
x
разрешения, что вполне возможно дляroot
пользователя:источник
/proc/kmem
) через отзыв возможности.Одним из примеров может быть изменение неизменного файла: Вы можете установить атрибут файла
i
с ,chattr
что делает файл непреложных даже для корня. Например:Обратите внимание, что файл отображается как
ls -l
выходной файл для записи :Чтобы увидеть
i
атрибут, вы должны использоватьlsattr
:Страница руководства chattr гласит следующее об
i
атрибуте:Хотя root может легко отменить неизменность:
источник
На FreeBSD вы не можете использовать
gmirror
уже смонтированный раздел, даже с правами root:Вы должны установить
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-время файла (или время рождения, если оно когда-либо реализовано)
не может просматривать пароли в виде простого текста
источник