¿Qué derechos de acceso no puede violar el superusuario?

El p. Br. George dijo en una de sus conferencias (está en ruso) que hay algunos derechos de acceso que el superusuario no puede violar. Es decir, hay algunos derechos de acceso que pueden prohibir que el superusuario haga algo.

No pude encontrar esta información en Internet y tengo curiosidad por saber qué son. Esto es probablemente algo relacionado con la ejecución central del sistema, ¿no? ¿Quizás no puede detener algunos procesos del sistema? ¿O tal vez no puede ejecutar un proceso en modo real?

Esta pregunta no está relacionada con SELinux (George estaba hablando de eso justo antes de la pregunta).

acceso denegado a root :

rootse le puede negar el acceso directo a la red. Esto es útil en los hosts conectados a Internet, ya que requiere que usted está registrado como smith, a continuación sudo.

algunas cosas que la raíz no puede hacer :

Esto NO es por falta de privilegios. No puedo ver nada que root no pueda hacer, sin embargo, algunos problemas técnicos pueden experimentarse como "prohibidos".

Soy root, ¿por qué no puedo crear / eliminar este archivo, mientras que el usuario común sí?

Está en un recurso compartido NFS / samba, y no recibió access=autorización específica ( ). El usuario ordinario no cumple con el derecho consuetudinario. (vea la raíz local frente a la remota a continuación)

Soy root, ¿por qué no puedo matar este proceso?

Hay una E / S pendiente y la unidad física / LUN remoto se ha desconectado, el proceso solo se puede eliminar al reiniciar.

Soy root, ¿cómo obtengo la contraseña de archemar?

Puede estar su - archemarbien o cambiar la contraseña de archemar sin conocer la anterior, pero no puede leerla (salvo un registrador de teclas), ya que las contraseñas se almacenan utilizando un hash unidireccional.

raíz local vs remota

• Puede ser root en su estación / PC, y utilizar un recurso compartido NFS de empresa / colegio / universidad / proveedor.
• A continuación, solo puede tener un inicio de sesión no root en la computadora que exporta NFS.

Ahora

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

simplemente inicie sesión en el servidor NFS, ejecútelo ./bashy será root en el servidor de la empresa / universidad.

En el caso habitual, esto es incorrecto: el superusuario tiene privilegios / permisos para cualquier funcionalidad que proporcione el sistema (1). Cuando esta regla se rompe es cuando lanzas SELinux a la mezcla. Con SELinux, es posible restringir incluso los privilegios de root para no permitir ciertas acciones. Sin embargo, las acciones específicas no permitidas dependen en gran medida de la configuración SELinux de la máquina local, por lo que incluso con SELinux, esta pregunta no puede responderse en el sentido general.

(1) - si un sistema no proporciona una característica dada, por ejemplo, no hay una funcionalidad del kernel en tiempo real, entonces estoy considerando que la declaración "root no tiene acceso a esta funcionalidad" es falsa, ya que esa declaración se basa en un suposición falsa (es decir, que la función dada está disponible para cualquier persona en ese sistema)

Por un lado, hay cosas que ningún usuario puede hacer, como

• directorios de enlace rígido (debido a limitaciones del sistema de archivos)
• escribir en un CD-ROM ya grabado (porque la física)

Pero esos no son privilegios, porque no se pueden otorgar, simplemente no son posibles para nadie.

Luego, existen restricciones para todo el sistema o partes del mismo que se pueden activar o desactivar.
Por ejemplo, en OS X hay una opción para permitir que el código solo se ejecute si Apple lo ha firmado.

Tampoco considero esto un privilegio real, porque ningún usuario puede tenerlo si el superusuario no puede. Solo puede deshabilitarlo globalmente.

Editar:
su idea de un archivo sin el bit ejecutable también entraría en esta categoría, ya que literalmente nadie puede hacerlo y nadie puede obtener ese permiso.
E incluso cuando se le da permiso a otro usuario o grupo para ejecutar ese archivo, pero no se encuentra la raíz o la raíz de un grupo de usuarios, la raíz aún podrá ejecutar ese archivo (probado en OS X 10.10, 10.11 y el servidor Ubuntu 15.04).

Aparte de esos casos, apenas hay nada que la raíz no pueda hacer.
Sin embargo, hay una cosa llamada modo kernel (en oposición al modo de usuario).

Hasta donde sé, en un sistema cuerdo, solo el núcleo, las extensiones y los controladores del núcleo se ejecutan en modo kernel, y todo lo demás (incluido el shell desde el que inicia sesión como root) se ejecuta en modo de usuario.
Por lo tanto, podría argumentar que "ser root no es suficiente". Sin embargo, en la mayoría de los sistemas, el usuario root puede cargar módulos de kernel, que a su vez se ejecutarán en modo kernel, lo que le dará a la raíz una forma de ejecutar código en modo kernel.

Sin embargo, hay sistemas (como iOS) en los que esto no es (arbitrariamente) posible, al menos no sin explotar todos los niveles de seguridad. Esto se debe principalmente a una mayor seguridad, como la aplicación de la firma de código.
Por ejemplo, hay claves de cifrado AES integradas en los procesadores de iDevices, a las que solo se puede acceder desde el modo kernel. Los módulos del núcleo podrían acceder a ellos, pero el código en esos módulos del núcleo también tendría que estar firmado por Apple para que el núcleo los acepte.

En OS X, desde la versión 10.11 (El Capitan) también existe el llamado "modo sin raíz" (aunque el nombre es engañoso porque la raíz aún existe), que efectivamente prohíbe la raíz de ciertas cosas que los instaladores pueden hacer.
Citando esta excelente respuesta en AskDifferent :

Esto es lo que restringe, incluso desde la raíz:

• No puede modificar nada en / System, / bin, / sbin o / usr (excepto / usr / local); o cualquiera de las aplicaciones y utilidades integradas. Solo el instalador y la actualización de software pueden modificar estas áreas, e incluso solo lo hacen al instalar paquetes firmados por Apple.

La "ejecución central del sistema" que está mencionando está muy bajo rootcontrol, por ejemplo, a través de módulos de núcleo cargables. Por supuesto, esto supone que la carga de los módulos del kernel es compatible con el kernel, nadie puede realizar acciones que ni siquiera son factibles root.

Lo mismo es cierto para los procesos del sistema. rootestá permitido matar cualquier proceso, pero es imposible detener un proceso que se ejecuta en modo kernel sin comprometer la integridad del kernel, por lo que simplemente no es factible detener dicho proceso de inmediato. Tenga en cuenta que rootno se negará a matar esos procesos, la muerte en sí misma simplemente no tendrá ningún efecto.

Finalmente, el modo real: el kernel de Linux no tiene soporte para él, por lo que, de nuevo, nadie puede hacer lo inviable, ni siquiera root.

@Siguza mencionó la ejecución de archivos sin el xpermiso, lo cual es bastante posible para el rootusuario:

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

Un ejemplo podría ser la modificación del archivo inmutable: Se puede establecer un atributo de archivo icon el chattrque hace que el archivo inmutable, incluso para el usuario root. Por ejemplo:

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

Tenga en cuenta que el archivo aparece como archivo de escritura normal en la ls -lsalida:

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

Para ver el iatributo, debe usar lsattr:

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

La página del manual de chattr dice lo siguiente sobre el iatributo:

Un archivo con el atributo 'i' no se puede modificar: no se puede eliminar ni renombrar, no se puede crear ningún enlace a este archivo y no se pueden escribir datos en el archivo. Solo el superusuario o un proceso que posee la capacidad CAP_LINUX_IMMUTABLE puede establecer o borrar este atributo.

Sin embargo, la raíz puede deshacer fácilmente la inmutabilidad:

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

En FreeBSD, no puede usar gmirroren una partición ya montada, incluso como root:

etiqueta gmirror -v -b prefiero gm0s1 ad4s1
gmirror: No se pueden almacenar metadatos en ad4s1: Operación no permitida.

Tienes que establecer un sysctl( kern.geom.debugflags=16) para poder hacerlo.

rootes un usuario privilegiado, pero estos derechos los otorga el núcleo. Entonces el núcleo tiene más privilegios que root.

Asumiendo la colaboración del propio usuario root, rootse puede evitar el acceso a los montajes FUSE (con las opciones allow_otheru allow_root), pero esto se debe a que FUSE fue diseñado para actuar de esta manera. Dado que FUSE reside en una capa virtual, puede devolver cualquier error que desee en función de la lógica, a diferencia de los módulos de dispositivos de bloque comunes que se esfuerzan por ser lo más transparentes y delgados posibles, delegando permisos a otra capa.

Esto no impide que el usuario root desactive la opción o reemplace el módulo FUSE por uno que descarte silenciosamente la opción, a menos que haga que el sistema de archivos sea de solo lectura. Sin embargo, esto solo lleva a una situación de "quién vigila a los vigilantes": ¿cómo puede validar que el sistema no está mintiendo? Su shell incluso podría estar sentado en un chroot que le muestra un módulo FUSE legítimo, mientras que el núcleo está ejecutando una versión malévola.

Diría que la imposibilidad de ejecutar archivos no ejecutables es trivialmente una limitación, ya que depende de los permisos de los archivos. (Es posible solucionar esto usando /lib64/ld-linux-x86-64.so.2 para un archivo no ejecutable, pero no un archivo en un montaje no exec)

También está el problema de los bloqueos de archivos obligatorios, que impiden la edición de archivos si un archivo está siendo utilizado actualmente por un proceso, aunque el superusuario puede matar el proceso.

En un momento, el superusuario no pudo desmontar un dispositivo mientras el dispositivo estaba ocupado, pero esto ahora se puede hacer usando un montaje lento.

Otras limitaciones son:

no puede modificar archivos inmutables, y solo puede agregar archivos adjuntos (linux le permite al superusuario eliminar los inmutables y agregar solo indicadores en cualquier nivel de ejecución, sin embargo, en parte contrarresta el propósito de ellos)

no puede escribir en una montura de solo lectura o ejecutar nada en una montura no ejecutiva

no se puede unir a una montura inquebrantable

no puede volver a montar un sistema de archivos como lectura-escritura si su dispositivo de bloque es de solo lectura

no puede registrar nada en un fusible de otro usuario, a menos que esté montado allow-other o allow-root

no puede violar la configuración de SELinux

limitaciones deliberadas inherentes al sistema en sí, que afectan la raíz:

no puede establecer directamente el tiempo c de un archivo (o la hora de nacimiento, si alguna vez se implementa)

no puede ver las contraseñas como texto sin formato