Mito o realidad: ¿SELinux puede limitar al usuario root?

Leí u oí en alguna parte (tal vez en el curso SELinux de LinuxCBT ; pero no estoy seguro) que hay servidores Linux en línea, para los cuales también se proporciona la contraseña del usuario raíz. El servidor Linux se fortalece utilizando las reglas de SELinux, de modo que todos puedan iniciar sesión con el usuario raíz, pero no pueden dañar el sistema operativo.

Me parece un mito, pero quería asegurarme: ¿Es posible fortalecer una caja de Linux (posiblemente con SELinux), de modo que incluso el usuario root no pueda realizar actividades maliciosas específicas en ella? (Ejemplos: eliminar archivos del sistema, borrar archivos de registro, detener servicios críticos, etc.)

Tal caja de Linux será un gran punto de partida para construir un honeypot .

Editar: según una respuesta (ahora eliminada) y un poco de Google, obtuve al menos dos enlaces que señalaban a servidores Linux tan duros. Desafortunadamente, ambos servidores están caídos. Para el registro, copiaré y pegaré las descripciones aquí:

1) De http://www.coker.com.au/selinux/play.html :

¡Acceso root gratuito en una máquina SE Linux!

Para acceder a mi máquina de juego Debian ssh a play.coker.com.au como root, la contraseña es ...

Tenga en cuenta que tales máquinas requieren mucha habilidad si quiere ejecutarlas con éxito. Si tiene que preguntar si debe ejecutar uno, la respuesta es "no".

El objetivo de esto es demostrar que SE Linux puede proporcionar toda la seguridad necesaria sin ningún permiso de Unix (sin embargo, todavía se recomienda que use los permisos de Unix también para servidores reales). También le da la oportunidad de iniciar sesión en una máquina SE y ver cómo es.

Cuando inicie sesión en una máquina de juego SE Linux, asegúrese de utilizar la opción -x para deshabilitar el reenvío X11 o establecer ForwardX11 no en su archivo / etc / ssh / ssh_config antes de iniciar sesión. También asegúrese de utilizar la opción -a para deshabilitar el reenvío del agente ssh o establecer el ForwardAgent no en su archivo / etc / ssh / ssh_config antes de iniciar sesión. Si no deshabilita correctamente esta configuración, iniciar sesión en la máquina de juego lo pondrá en riesgo de ser atacado a través de su cliente SSH.

Hay un canal IRC para discutir esto, es #selinux en irc.freenode.net .

Aquí hay un FAQ rápido

2) De http://www.osnews.com/comments/3731

El propósito de Harnto Endurecido es hacer que Gentoo sea viable para entornos de servidores de producción de alta seguridad y alta estabilidad. Este proyecto no es un proyecto independiente separado de Gentoo propiamente dicho; Está destinado a ser un equipo de desarrolladores de Gentoo que se centran en ofrecer soluciones a Gentoo que brinden una seguridad y estabilidad sólidas. Esta máquina es la máquina de demostración SELinux de Hardened Gentoo . El uso principal de este es probar y auditar la integración y la política de SELinux.

Realidad: sí, SELinux puede limitar al usuario root.

Esto es posible porque a SELinux en realidad no le importa el usuario actual de Unix: todo lo que ve es un metadato complementario llamado contexto (que incluye, entre otros campos, un campo de dominio ) y que le permite a SELinux decidir si la acción solicitada puede ser autorizada o no. no.

Lo que generalmente se concibe como el usuario raíz se mapearía en SELinux como un usuario raíz de Unix que ejecuta los dominios unconfined_to sysadm_tSELinux. Es el usuario root omnipotente clásico con plena potencia.

Sin embargo, uno podría configurar perfectamente su sistema para generar un shell raíz (me refiero al shell de usuario root de Unix) que ejecuta el user_tdominio SELinux de usuario restringido . Según las políticas de SELinux, dicho shell no sería diferente de los demás shells de usuarios restringidos y no tendría ningún privilegio especial en el sistema, lo que limitaría efectivamente al usuario root.

Aparte de un punto de vista experimental, hacer tal cosa literalmente es inútil, sin embargo, una práctica similar encuentra su camino en el mundo real. Un ejemplo clásico sería un administrador de base de datos que necesita poder detener / iniciar los daemons de la base de datos, editar archivos de configuración, etc. Sin SELinux, todas estas acciones requerirían que el usuario escale hacia privilegios de root (incluso si normalmente es para un solo línea de comando a través de la sudoherramienta, por ejemplo, sin embargo, incluso eso puede ser propenso a fugas).

Gracias a SELinux, podríamos darle a este usuario un shell raíz genuino, pero en lugar de ejecutar unconfined_to sysadm_tdominios, ejecutará el dbadm_tdominio. Esto significa que tendrá más privilegios que un usuario restringido, pero estos nuevos privilegios se limitarán a lo que se necesita para administrar el servidor de la base de datos: este usuario no podrá manipular otros servicios, archivos o ejecutar otros comandos administrativos que esos estrictamente requerido para hacer su trabajo.

Del mismo modo, el servidor web y otros administradores de servicios también podrían tener otros shells raíz ejecutándose en paralelo en el mismo sistema, cada uno verá que su usuario actual de Unix es root , pero gracias a SELinux cada uno tendrá privilegios efectivamente diferentes limitados a lo que es necesario para sus propios fines .

Si es posible. Pero no muy útil.

Teóricamente, podría impedir que el usuario raíz ejecute archivos binarios que podrían usarse con fines maliciosos, aplicando políticas a través de algo como SELinux. Sin embargo, esto presenta un problema, que es que incluso si el usuario raíz no pudo hacer algo inicialmente, él o ella podrían usar otros métodos para cambiar o eliminar las políticas de SELinux. Debido a este problema, tendría que impedir que el usuario root realice cualquier acción, por lo que no es muy útil.

¿Es posible endurecer una caja de Linux (posiblemente con SELinux), de modo que incluso el usuario root no pueda realizar actividades maliciosas específicas en ella?

Esto puede sonar barato, pero es fácil: cambie el uid de la raíz del usuario a no cero. Simplemente vaya a / etc / passwd y / etc / shadow, modifique las entradas existentes uid = 0 de "root" a otra cosa, y luego agregue una cuenta llamada "root" cuyo uid no sea cero y no se use.

Logra el propósito sin. También es una forma de afirmar que cualquiera puede tener "acceso raíz" sin proporcionar realmente privilegios escalados.