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).
root
privileges
access-control
Kolyunya
fuente
fuente
root
ningún derecho y, por lo tanto, no se puede quitar ningún derechoroot
.SECBIT_NOROOT
, y siendo uid 0 ya no otorga una capacidad automáticamente.Respuestas:
acceso denegado a root :
root
se 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 comosmith
, a continuaciónsudo
.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".
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)Hay una E / S pendiente y la unidad física / LUN remoto se ha desconectado, el proceso solo se puede eliminar al reiniciar.
Puede estar
su - archemar
bien 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
Ahora
simplemente inicie sesión en el servidor NFS, ejecútelo
./bash
y será root en el servidor de la empresa / universidad.fuente
root
localmente, 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.root
en una máquina local podría hacer lo que quiera con el mismo privilegio que el usuario local, porsu - username
lo menos. Nunca estoy seguro de por qué se molestaron enroot
no poder escribir recursos compartidos de red como ese; Parece bastante inútil.root
crear una contraseña incluso si él no puede acceder?"root
acceso 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.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)
fuente
Por un lado, hay cosas que ningún usuario puede hacer, como
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 :
fuente
gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hello
da elHello, World!
resultado esperado ,/lib64/ld-linux-x86-64.so.2
el ejecutable real entonces, y./hello
solo 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 usandobash ./my_script
...La "ejecución central del sistema" que está mencionando está muy bajo
root
control, 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 factiblesroot
.Lo mismo es cierto para los procesos del sistema.
root
está 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 queroot
no 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
x
permiso, lo cual es bastante posible para elroot
usuario:fuente
/proc/kmem
) mediante la revocación de la capacidad.Un ejemplo podría ser la modificación del archivo inmutable: Se puede establecer un atributo de archivo
i
con elchattr
que hace que el archivo inmutable, incluso para el usuario root. Por ejemplo:Tenga en cuenta que el archivo aparece como archivo de escritura normal en la
ls -l
salida:Para ver el
i
atributo, debe usarlsattr
:La página del manual de chattr dice lo siguiente sobre el
i
atributo:Sin embargo, la raíz puede deshacer fácilmente la inmutabilidad:
fuente
En FreeBSD, no puede usar
gmirror
en una partición ya montada, incluso como root:Tienes que establecer un
sysctl
(kern.geom.debugflags=16
) para poder hacerlo.root
es un usuario privilegiado, pero estos derechos los otorga el núcleo. Entonces el núcleo tiene más privilegios queroot
.fuente
Asumiendo la colaboración del propio usuario root,
root
se puede evitar el acceso a los montajes FUSE (con las opcionesallow_other
uallow_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.
fuente
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
fuente