En realidad, es posible restringir el root si uno está preparado para definir tal restricción como confiar fundamentalmente en el sistema operativo . Esto se puede hacer usando SELinux (que yo sepa) y presumiblemente otros sistemas similares. El mejor ejemplo que he visto de SELinux usado de esta manera es Play SELinux Machine de Russell Coker.

Como una breve descripción de cómo funciona, el nombre "root" es no es especial en Unix. El UID 0 es. Se entiende que UID 0 significa "confiar en todo lo que digo". Esto se aplica específicamente al modelo de acceso estándar que se usa en Unices, Unixen o como se utilice en plural "Unix".

LSM, o módulos de seguridad de Linux, le permite conectarse a casi todo y auditar / denegar acciones a medida que consideran necesario. En el caso de SELinux, los permisos de SELinux se verifican después de los permisos de Unix, por lo que su flujo se ve así:

  Evento ---- > ¿Tiene permisos de Unix? --- ¿> tiene permisos de SELinux? --- > Deje que suceda  

La siguiente etapa a entender es que existen, o han existido históricamente, diferentes versiones de la Política de SELinux. Antes de entrar en eso, entienda que en SELinux:

• los inodos tienen tipos, con el sufijo _t , que también podrían llamarse dominios; y
• los usuarios tienen roles, con el sufijo _r.

Combinados, controlan qué acción puede hacer un usuario en un rol dado, y qué un proceso en un dominio determinado puede funcionar.

Ahora, hay tres políticas principales de SELinux:

1. dirigido. Esta es la política predeterminada para escritorios como Fedora. La idea de focalizado es que los servicios críticos del sistema y los demonios se ejecutan en dominios, pero mucho de lo que hace el usuario final se ejecuta en inconfined_u: inconfined_r: inconfined_t . No hay premios por adivinar lo que eso significa: si los permisos de Unix funcionan, SELinux se transfiere efectivamente.
2. estricto. Esta política implica eliminar inconfined_u por completo. Este no es un proceso fácil, especialmente en el escritorio de Linux (es decir, init 5 ). Específicamente, el modelo de seguridad X11 no es excelente y, a menudo, requiere unsinfined_t para algunas aplicaciones. puede hacer esto, pero esperaría que trabajar con X11 sea más difícil (aunque no imposible), especialmente cuando se ejecutan aplicaciones GUI que requieren root. Hay un proyecto en marcha para brindar soporte para la funcionalidad similar a SELinux en X, llamado XACE (X Access Control Extensions).
3. MLS. MLS significa para seguridad multinivel y significa el final de la cadena de permiso: user_u: system_r: httpd_content_t.s0-s2: c5-c7 , es decir, esos s y c los números realmente significan algo. Específicamente, forman una configuración de no leer, no escribir de modo que, a menos que el proceso se esté ejecutando a un cierto nivel, la información que pueden ver será limitada. La idea de este nivel de información es proteger los activos clasificados: SELinux fue desarrollado originalmente por la NSA, presumiblemente para este propósito.

Así que esa es su experiencia. Ahora, de acuerdo con las páginas web (consulte las Preguntas frecuentes), la raíz es UID 0 en la máquina de reproducción; sin embargo, root está configurado para ejecutarse como user_r y no como sysadm_r en la política estricta . Esto significa que al usuario no se le permitirá ejecutar funciones administrativas desde el shell.

Lo que sería interesante saber, entonces, es el estado de los otros procesos que requieren root. Es de suponer que dichos procesos se han etiquetado adecuadamente y tienen políticas que les permiten el acceso que requieren. La pregunta entonces es cómo se administra el sistema y si alguno de estos procesos puede lanzar un shell en el contexto de ese usuario. Si eso puede suceder, aún puede administrar un exploit.

Dado que la máquina de juego está actualmente inactiva (al momento de escribir este artículo), estoy trabajando en supuestos aquí; pero esencialmente, necesitaría un proceso que se ejecute en sysadm_r y con UID 0 como su objetivo para un exploit. Asumiendo que tal proceso existe y es explotable, aún podría llegar a la raíz. En cuanto a seguir siendo capaz de administrar a través de root, hay dos opciones en las que puedo pensar:

• O hay una transición confiable de algún tipo que significa que root luego puede hacer la transición a sysadm_r (menos seguro) o
• En diferentes niveles de ejecución, se aplica una política diferente, por lo que para administrar la máquina, uno establece el nivel de ejecución en 1 y la política no restringe la raíz. . Supongo que aquí.

Resumen

Si su pregunta es "¿puedo hacer esto ahora de manera fácil y segura?" la respuesta es no. Si su pregunta es "Estoy preparado para aprender acerca de SELinux, ensuciarme con mi distribución y aguantar muchas cosas que no funcionan", la respuesta es que es posible restringir el root mucho más que la instalación promedio. Dicho esto, esto no lo hace invulnerable de ninguna manera a los exploits; no hace que sea imposible para un usuario eludir este control de acceso adicional, ya sea en el software o físicamente.

Entonces sí, puede hacer cosas invisible para la raíz; sin embargo, dejando de lado la carga técnica adicional, se aplican las mismas advertencias que a cualquier configuración de control de acceso en cualquier usuario normal; no hay una fórmula mágica.

Ah, y autopromoción descarada: es posible que le guste mi publicación de blog almacenar secretos en software. Está en el blog de security stackexchange, así que no me siento tan mal por promocionarlo. Esencialmente, como puede ver, existen mecanismos para hacer la vida mucho más difícil para un atacante (y para usted), pero al final, es un caso de "tortugas hasta el fondo", es decir, fundamentalmente imposible de hacer.

Tuve que abordar este problema antes, cuando se me acercó un cliente que quería mantener seguros los "mensajes privados" entre los usuarios de un sitio web. Es posible proteger algunos datos en algunas circunstancias, pero esto es razonablemente limitado.

Mi enfoque fue simplemente almacenar una versión encriptada de la nota en el servidor y enviarla (una vez autenticada, por supuesto ), luego descifrelo completamente del lado del cliente. Esto significa que incluso en el caso de un compromiso total de la seguridad del servidor (es decir, acceso de root), las notas permanecen seguras. Sin embargo, las limitaciones de esto:

• Los datos protegidos solo están seguros hasta el punto de compromiso, y no más tarde. Dependiendo del método utilizado para cifrar la información, un servidor rooteado puede engañar al usuario para que revele las claves de descifrado (inyección de JavaScript, o para clientes GUI nativos, emitiendo una actualización de cliente comprometida) o interceptando las claves de descifrado (si las claves están basadas en del mismo método que la autenticación del usuario, como una contraseña, pueden ser interceptados durante el proceso de autenticación del lado del servidor).
• La transmisión requiere un secreto directo perfecto, de lo contrario, los datos cifrados podrían ser interceptados, almacenados y luego descifrado después del compromiso como se discutió anteriormente.
• Esto no protege nada si el cliente también está comprometido. A menos que esté procesando datos encriptados completamente en su propia cabeza (y si puede, se merece un trofeo o algo así), estará dando datos confidenciales a algo , y nada es perfectamente intransigente.
• No hay forma de utilizar estos datos del lado del servidor (es decir, para fines de indexación) a menos que se almacenen metadatos descifrables / en texto plano al lado, lo que puede revelar información adicional.

Básicamente, esto limita los usos potenciales de este escenario y todavía existen debilidades, pero es posible que funcione en algunas situaciones. El hash de contraseña es un ejemplo (razonablemente) exitoso de 'protección contra el compromiso de root', ya que incluso el acceso físico no revelará las contraseñas de un usuario (excepto, por supuesto, si esa contraseña se transmite después del compromiso).

Hay otros ejemplos en este hilo que vale la pena analizar también, pero piense un poco en el escenario de procesamiento del lado del cliente, usando el servidor simplemente como un servicio de almacenamiento seguro.

TC

¿Puede haber archivos en el sistema de archivos que no sean accesibles incluso para la raíz completa de ninguna manera, pero accesibles para algunos procesos? ¿Algunos procesos actualmente en ejecución, o incluso procesos nuevos iniciados por los procesos que actualmente tienen acceso?

No. Cuando un proceso puede acceder a ellos, también puede root. Si desea hacer tales cosas, tendrá que modificar en gran medida todo el sistema, posiblemente un sistema que arranca un kernel inmutable desde algún dispositivo de solo lectura y que niega a root ciertos accesos a archivos / memoria mientras se los permite a otros usuarios que root pueden ' t suplantar.

¿Se pueden mantener secretos en la memoria ejecutando procesos de modo que incluso la raíz completa no pueda acceder a ellos de ninguna manera? ¿Se pueden transmitir estos secretos a nuevos procesos por algún medio que la raíz no pueda afectar?

No. Consulte la respuesta anterior.

No puede, por definición, restringir el acceso de root. Si limita el acceso de root, entonces ya no es un usuario root.

Si quisiera denegar el acceso de root a los secretos, trataría de ocultarlos. Contenedores criptográficos, tal vez ocultos en la memoria de intercambio o en otro lugar y solo accesibles con una contraseña o algún otro tipo de esteganografía. Es muy difícil encontrar una aguja en un pajar, aunque no imposible.

Hay varias formas indirectas a través de las cuales root puede terminar ejecutando código arbitrario. Puede deshabilitarlos y, de hecho, algunos marcos de seguridad pueden deshabilitarlos, pero paralizan la capacidad de root para realizar tareas de administración.

Por ejemplo, root puede leer y escribir en discos directamente, sin pasar por todo tipo de sistemas de archivos. permisos. Puede eliminar esta capacidad, pero el root no podrá mover un sistema de archivos completo a un nuevo disco en caso de emergencia.

El root puede cargar módulos del kernel y, por lo tanto, puede hacer todo lo que el kernel puede hacer. . Puede eliminar esta capacidad, pero luego excluye la carga de controladores para medios conectables en caliente. (Esto puede ser deseable en el .001% de las instalaciones de Unix, pero no es el caso general).

La raíz puede actualizar los ejecutables que permiten a los usuarios iniciar sesión, como login o sshd . Estos demonios manejan la autenticación de usuarios, por lo que si controlas su código, puedes inyectar una puerta trasera. Puede eliminar esta capacidad, pero la raíz no podrá realizar actualizaciones de seguridad.

La raíz puede crear y eliminar usuarios y cambiar las credenciales de autenticación: si puede editar / etc / passwd para agregar una cuenta, también puede editarla para convertirla temporalmente en una cuenta sin contraseña. Puede eliminar esta capacidad haciendo que algunos archivos sean de solo lectura incluso para root, pero luego terminará con un sistema en el que no podrá crear o eliminar cuentas de usuario sin reiniciar.

Los marcos de seguridad crean de manera efectiva usuarios de root limitado que son root solo en un subconjunto del sistema - root solo en una máquina virtual, no en el sistema "real". Esta raíz limitada pierde la posibilidad de realizar tareas de administración en el sistema real. Creo que la virtualización es lo que busca.

Esto se logra con relativa facilidad mediante el uso de un sistema selinux de "dos claves": root no tiene permisos para hacer nada, y algún otro usuario sin permisos de root sí , así que para cambiar cosas, primero necesita para ser el otro usuario no root, entonces "su" a root para realizar el cambio.

Ninguno de los usuarios de forma aislada puede hacer o ver nada.

Estoy usando esto . Funciona realmente bien.

Como dijo Falcon, el usuario root por definición tiene acceso a todas esas cosas, o ya no es el usuario root.

El kernel controla todo el hardware, así que una vez que eres root tienes el mismo acceso. Realmente necesita virtualización, por lo que su usuario root es solo root para el sistema operativo virtualizado en el que se está ejecutando y algún hipervisor se encuentra fuera de esa root . (no quiere decir que los hipervisores no sean explotables, pero lo que está intentando hacer es equivalente a esto).

¿Has probado Grsecurity? Puede restringir efectivamente a los usuarios root de todas las formas posibles. https://grsecurity.net/

Grsecurity, junto con PaX hace de tu caja una fortaleza inexpugnable ... si lo haces bien

La necesidad real no está bien definida en la pregunta, pero no se han mencionado dos posibles soluciones a las que se alude:

• Contenedores
• HSM

Los contenedores, que por supuesto son solo un enfoque más sensato desde el punto de vista arquitectónico de lo que se estaba haciendo poco a poco con herramientas como cárceles y SELinux, pueden ser de relevancia en el contexto de un replanteamiento de la pregunta, ¿hay una forma en que un sistema lógico similar a Unix puede estar expuesto a atacantes de manera que pueda estar comprometido con la raíz, pero los secretos del sistema físico aún están protegidos. Con los contenedores nos estamos acercando a este objetivo. Vale la pena leer un artículo reciente del grupo de seguridad NCC: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

Los HSM son dispositivos de cifrado de hardware que evitan la recuperación de claves de descifrado a través de métodos físicos o lógicos, por lo que puede ser una respuesta a la pregunta reformulada como: Tengo secretos que tengo que descifrar de forma segura, ¿qué hago con las claves?