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

23

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).

Kolyunya
fuente
2
Un "privilegio" o "permiso" es un derecho a hacer algo, un derecho que se puede otorgar a cuentas de usuario específicas. En UNIX y Linux (excluyendo versiones reforzadas como SELinux), la raíz tiene todos los derechos. No se puede otorgar rootningún derecho y, por lo tanto, no se puede quitar ningún derecho root.
MSalters
1
@MSalters, perdón? Ciertamente, se puede mantener UID 0 sin dejar de revocar las capacidades del proceso.
Charles Duffy
... establecido SECBIT_NOROOT, y siendo uid 0 ya no otorga una capacidad automáticamente.
Charles Duffy
Tantas respuestas: ¿tendría sentido convertir esto en un wiki comunitario o alguien debería escribir una respuesta resumida?
Simon Richter
1
@SimonRichter También iré como George para decirnos qué quiso decir en su conferencia.
Kolyunya

Respuestas:

24

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.

Archemar
fuente
El caso 1 es básicamente un error porque solo estás rootlocalmente, no necesariamente en otros sistemas. Los casos 2 y 3 no son privilegios (no se pueden otorgar a nadie). Entonces +1, su primera oración parece ser correcta.
MSalters
Técnicamente, rooten una máquina local podría hacer lo que quiera con el mismo privilegio que el usuario local, por su - usernamelo menos. Nunca estoy seguro de por qué se molestaron en rootno poder escribir recursos compartidos de red como ese; Parece bastante inútil.
Tom Hunt
44
Es la vieja pregunta "¿Puede rootcrear una contraseña incluso si él no puede acceder?"
corsiKa
55
@TomHunt, una de las razones para no dar rootacceso a los recursos compartidos de NFS es evitar la creación de binarios "suid root" en el servidor remoto, algo que se puede aprovechar para obtener acceso remoto completo al servidor.
Mark
1
Matar un proceso en espera ininterrumpida no me parece un derecho . Es algo que simplemente no puedes hacer. Como escribir en un sistema de archivos completo.
Blacklight Shining
11

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)

John
fuente
1
¡Gracias por tu respuesta, John! Pero él declaró explícitamente que esta pregunta no está relacionada con SELinux ...
Kolyunya
Luego, salvo más detalles, voy a tener que considerar que la afirmación de que root no tiene acceso a ciertas funciones es falsa. (No estoy considerando el caso del sistema operativo que se cerró la puerta de la BIOS o similar de la seguridad del BIOS.)
John
También tiene la complicación de que root controla la configuración de SELinux. Si yo (como root) estoy bloqueado en una acción, puedo modificar SELinux para permitir la acción y luego volver a cambiarla. Podría salirse con la suya dependiendo de dónde esté almacenado el rastro de registro.
doneal24
2
No necesariamente cierto. Quite su CAP_NET_ADMIN, y ser uid 0 todavía no permite que un proceso cambie la configuración de la red. (Del mismo modo para CAP_SYS_ADMIN y las habilidades que controla, etc.).
Charles Duffy
5

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.
Siguza
fuente
1
En realidad, puede ejecutar un ejecutable sin el conjunto de bits de ejecución: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloda el Hello, World!resultado esperado ,
doneal24
@ DougO'Neal ¿Pero no es /lib64/ld-linux-x86-64.so.2el ejecutable real entonces, y ./hellosolo un argumento? Porque eso es como pasar un archivo de texto que contiene código PHP al intérprete PHP ... o como ejecutar un script bash usando bash ./my_script...
Siguza
1
@ DougO'Neal Eso solía funcionar, pero estaba deshabilitado en las versiones recientes de glibc (para evitar que sea una derivación trivial de los montajes noexec).
duskwuff
@duskwuff ¿Qué tan reciente es una versión de glibc? Esto todavía funciona bajo Ubuntu 14.04.
doneal24
1
Apple no lo agregó a ln, pero la clase de sistema que usa, por ejemplo, el enlace, lo permite, consulte stackoverflow.com/a/4707231/151019. Así funciona Time Machine
usuario151019
4

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
Dmitry Grigoryev
fuente
... pero un proceso uid-0 puede perder la capacidad de cargar nuevos módulos del kernel (o parcharlos en caliente /proc/kmem) mediante la revocación de la capacidad.
Charles Duffy
4

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’
Tuomas
fuente
El kernel de Linux ya no implementa correctamente la función de nivel seguro BSD (ya no), lo que le brinda rendimientos decrecientes en atributos inmutables y que solo agregan. Con securelevel , estos bits no se pueden restablecer una vez que el sistema está en un nivel de ejecución multiusuario, por lo que el administrador tendría que apagar y usar una consola local, lo que detendría a los atacantes de red.
Simon Richter
2

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.

Vinz
fuente
1

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.

sleblanc
fuente
0

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

otro muchacho
fuente