Estoy considerando el uso de SELinux para varios servidores de lámpara (linux + apache + mysql + php). He probado SELinux en una máquina virtual y he configurado algunas reglas básicas (permitir PHP, correo electrónico, etc.) y por el momento todo parece funcionar bastante bien. Pero me preocupa haber pasado por alto algunas trampas. ¿Cuáles son algunos de los problemas comunes de habilitar SELinux para servidores LAMP que son fáciles de pasar por alto?
Si la regresión ha probado todo y no se ha encontrado ningún problema insuperable, entonces excelente, sin embargo, mi experiencia es la opuesto a TorstenS : creo que se traduce en una disminución neta de la seguridad de su sistema, excepto en los escenarios específicos (y es poco probable que" el servidor LAMP "caiga dentro de esa categoría) que figuran en la publicación vinculada.
Para resumir: la complejidad, la abstracción opaca y la documentación deficiente hacen que sea muy difícil entender la implementación y adaptarla a propósitos específicos. Hay poca evidencia de que incluso una instalación configurada por expertos sea más segura que un sistema que no aplique una política. Si bien intrínsecamente es poco probable que aumente su superficie de ataque, es probable que resolver la funcionalidad que el desempeño impacta (es decir, comprometer la política estándar suministrada por su proveedor) socavará la seguridad general del sistema de maneras que no lo hace. No entiendo.
Como dice Schroeder, es demasiado amplio. Sin embargo, me gustaría agregar dos bits de comparación concreta de los complementos setroubleshoot que dan malas pistas sobre la seguridad.
Primer ejemplo, el servidor web de puertos de red puede conectarse. Establecí redis como el almacén de sesiones en lugar de archivos para PHP. Prefiero conectarme a través del puerto TCP en lugar del socket. Por lo tanto, el consejo dado por sealert está activando httpd_can_network_connect boolean. Pero es mejor simplemente permitir el puerto específico, en este caso, redis_port_t , y no todos los puertos:
module httpd_connect_redis 1.0.0;
require {
class tcp_socket { name_connect };
type httpd_t;
type redis_port_t;
}
allow httpd_t redis_port_t:tcp_socket name_connect;
Segundo ejemplo, un caso lamentablemente no tan poco común en el que Plesk configura Apache y NginX para que se ejecuten en tándem, con el primero como el proxy inverso. Plesk configura Apache para que se ejecute en los puertos 7080 y 7081, sin reservar los mismos puertos en una política personalizada, no hablemos ahora de configurar binarios php-fpm como servicios no confinados (Mal Plesk, muy mal).
Si siguiera el consejo de setroubleshoot, permitiría NginX name_connect a cualquier puerto no reservado, o cualquier otro puerto que habilite el booleano httpd_can_network_connect , y no solo 7080 y 7081. En cambio, fue un poco más de trabajo, pero como en el caso de redis port, he creado un tipo personalizado para etiquetar esos dos puertos, y luego cierro los mensajes de auditoría, porque realmente no uso Apache para ejecutar mis aplicaciones web y solo uso Plesk porque mi jefe piensa Es una forma en que puede ver cómo se configuran los dominios. De todos modos, no es tan difícil escribir una política básica para crear etiquetas personalizadas para puertos personalizados, y configurar solo los permisos que necesita y no abrir todo rápidamente como lo permiten los booleanos, pero ejecutar todo sin restricciones no es mejor que tener SELinux deshabilitado.
module plesk_disallowed_apache_proxy 1.1.0;
type plesk_apache_behind_proxy_port_t;
require {
class tcp_socket { name_connect name_bind };
attribute port_type;
type httpd_t;
}
typeattribute plesk_apache_behind_proxy_port_t port_type;
dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_connect;
dontaudit httpd_t plesk_apache_behind_proxy_port_t:tcp_socket name_bind;