selinux: bloqueando el uso de sudo y su al colocar al usuario en el perfil de usuario_t

1

Estoy intentando bloquear las escaladas de privilegios de cuentas sin privilegios, como www-data .

Básicamente, si mi servidor web se ve comprometido, los crackers pueden encontrar formas de escalar (¿vulnerabilidades encontradas en sudo? ¿reutilización de contraseña raíz de otro servidor crackeado?). Quiero encontrar una manera de prohibir esto, y encontré que poner www-data en el perfil de user_u selinux tiene este efecto.

Sin embargo, mirando el archivo audit.log cuando www-data intenta sudo o su muestra esto:

Para sudo:

type=AVC msg=audit(1533818833.807:318): avc:  denied  { setuid } for  pid=1417 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability

Was caused by:
The boolean selinuxuser_use_ssh_chroot was set incorrectly. 
Description:
Allow selinuxuser to use ssh chroot

Allow access by executing:
# setsebool -P selinuxuser_use_ssh_chroot 1

Para su:

type=AVC msg=audit(1533818282.076:263): avc:  denied  { write } for  pid=1354 comm="su" name="btmp" dev="dm-0" ino=8428621 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file

Was caused by:
    Missing type enforcement (TE) allow rule.

    You can use audit2allow to generate a loadable module to allow this access.

Entonces, para sudo , parece más que un error (¿por qué selinuxuser_use_ssh_chroot ??!) y para su , el rechazo proviene de derechos insuficientes en /var/log/wtmp

¿Este método es eficaz para bloquear una posible escalada de usuarios no confiables? ¿O se ve más que un hack? ¿Es esto suficiente para evitar que un usuario comprometido con una contraseña de root obtenga acceso de root?

    
pregunta philippe 09.08.2018 - 14:59
fuente

1 respuesta

0

El mensaje sobre selinux_use_ssh_chroot es una sugerencia de diagnóstico basada en el AVC generado mensaje de negacion La denegación exacta es para la capacidad setuid y el booleano en cuestión habilitaría una regla que permitiera la operación, por lo que se sugirió automáticamente. De manera similar, se generó una sugerencia automática para una regla adicional que permite el acceso cuando intentó usar su . Se esperan mensajes de denegación de AVC si intenta obtener privilegios como usuario limitado.

Sin embargo, sus pruebas no reflejan cómo se comportaría el servidor web (apache o nginx) en un dominio confinado. De forma predeterminada, debería ejecutarse en el dominio confinado httpd_t . Si no hay una política orientada, el servicio se ejecutará en un dominio no limitado, no en user_t .

Si un servidor web restringido está comprometido, el atacante aún está confinado en httpd_t dominio y no puede obtener ningún permiso nuevo que originalmente no estaba permitido. No debería haber ninguna regla que permita que un proceso en httpd_t ejecute sudo / su . Incluso si el proceso pudiera administrar a root, sin ninguna regla de transición a otro dominio, el proceso permanecería en httpd_t y estaría restringido a las reglas para httpd_t .

    
respondido por el sebasth 13.08.2018 - 23:44
fuente

Lea otras preguntas en las etiquetas