Estoy tratando de entender qué permisos están permitidos por algunos de los booleanos de SELinux para el dominio httpd, ya que es mi principal fuente de preocupación, y la política actual de mi organización es otorgar el privilegio mínimo requerido para obtener un aplicación funcionando.
Leyendo con sesearch lo que hacen algunos booleanos, está claro que realmente no necesito algunos de ellos, así que los desactivamos. Por ejemplo, no necesitamos que nginx pueda conectarse a los puertos squid, ftp, gopher y memcache, entre otras cosas que permite el boolean httpd_can_network_relay , porque pasamos nuestras solicitudes a través de sockets. Boolean httpd_can_network_connect es demasiado amplio para nosotros, como el único puerto que necesitamos abrir, ya está etiquetado para redis y tenemos un módulo de políticas muy fácil de entender para eso: enlace
He luchado un poco para que funcionen algunos scripts PHP, incluso después de etiquetar cuidadosamente algunas rutas públicas, para permitir solo escrituras desde la aplicación web en las subidas y cachés de los directorios de captchas, pero sin dejar que la actualización se haga por sí sola o mágicamente. Descarga de scripts de terceros que podrían ser ejecutados. Además, solo se permite la ejecución de scripts en rutas específicas.
Ya tengo estos objetivos funcionando y la gente de fuera de TI está trabajando sin quejarse, pero aún no puedo entender por completo lo que permiten los booleanos que he tenido que habilitar, porque las páginas de manual son útil para habilitar algo rápidamente pero no entender cómo funciona magic . Y la salida de sesearch es demasiado confusa.
Por ejemplo: sesearch -AC -b httpd_anon_write permite comprender que solo está permitiendo escrituras en los objetos etiquetados public_content_rw_t , pero todavía no entiendo por qué no estaba funcionando con httpd_sys_content_rw_t .
Pero, la salida para los valores booleanos httpd_unified y httpd_builtin_scripting son conflictivos, y estoy francamente preocupado de permitir sin necesidad de demasiadas cosas. Especialmente en los objetos etiquetados con httpd_sys_rw_content_t , no pude hacer que las escrituras funcionaran sin habilitar ambos booleanos, y no habilité httpd_enable_cgi porque los permisos me parecen muy amplios. Vea la parte más confusa:
DT allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
ET allow httpd_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ httpd_builtin_scripting ]
Tal vez es que no llego a donde está el AND y si hay un OR , pero no entiendo por qué se permiten todas las operaciones de acuerdo con la regla anterior , simplemente habilitando httpd_builtin_scripting , y por qué de acuerdo con la primera regla, se debe habilitar ese mismo booleano, Y httpd_unified AND httpd_enable_cgi .
Honestamente, estaría más que contento de no depender de ningún booleano que permita más de lo estrictamente necesario, por eso le agradezco que me ayude a entender la sintaxis de los booleanos necesarios para una regla para ser habilitado.
FWIW, la aplicación web que estoy asegurando está basada en WordPress, y los tutoriales a su alrededor dependen de los booleanos sin explicar por qué son necesarios y qué riesgos presentan. A mi organización también le disgustan las actualizaciones automáticas para saltos de compatibilidad.