Diagnosticar las denegaciones de Squid bajo SELinux
Distinga las reglas de acceso de Squid, los permisos del sistema de archivos, las etiquetas de puerto y las denegaciones de la política de seguridad del host antes de cambiar la aplicación.
Una denegación de acceso HTTP generada por Squid y un “Permission denied” del sistema operativo ocurren en límites diferentes. Determine si Squid estaba abriendo un archivo, vinculando un socket, conectando hacia el exterior o rechazando una solicitud de cliente.
Correlacione el evento de auditoría
En sistemas SELinux, haga coincidir el error del servicio con su registro de auditoría. El dominio de origen, el tipo de destino, la clase de objeto y el permiso denegado muestran qué operación bloqueó la política. La propiedad correcta en Unix no demuestra que la etiqueta de seguridad sea adecuada.
Un puerto de escucha personalizado puede requerir la etiqueta de puerto correspondiente. Un directorio de registros o de caché reubicado puede requerir etiquetado de archivos. Para un fallo de la ruta de registro de Squid, compruebe también el recorrido de directorios y los permisos de escritura antes de atribuirlo a una etiqueta. El permiso para un servicio saliente inusual es otra operación más; los ejemplos de Squid SELinux de Red Hat distinguen estos casos.
Utilice la política de la distribución instalada y la guía de administración. Las rutas de los paquetes, las etiquetas y el confinamiento pueden variar entre imágenes. En sistemas que usan AppArmor, inspeccione su perfil en lugar de aplicar comandos de SELinux.
Corrija la política o la ubicación implicada por las pruebas mientras mantiene la aplicación en el host. La autenticación de clientes y las reglas de acceso propias de Squid siguen aplicándose después de reparar el problema de política del host.