Diagnosticar as denegacións de Squid baixo SELinux
Distinga as regras de acceso de Squid, os permisos do sistema de ficheiros, as etiquetas de porto e as denegacións da política de seguridade do host antes de cambiar a aplicación.
Unha denegación de acceso HTTP xerada por Squid e un “Permission denied” do sistema operativo ocorren en límites diferentes. Determine se Squid estaba abrindo un ficheiro, vinculando un socket, conectando cara a fóra ou rexeitando unha solicitude de cliente.
Correlacione o evento de auditoría
En sistemas SELinux, faga coincidir o erro do servizo co seu rexistro de auditoría. O dominio de orixe, o tipo de destino, a clase de obxecto e o permiso denegado mostran que operación bloqueou a política. A propiedade correcta en Unix non demostra que a etiqueta de seguridade sexa axeitada.
Un porto de escoita personalizado pode requirir a etiqueta de porto correspondente. Un directorio de rexistros ou de caché reubicado pode requirir etiquetado de ficheiros. Para un fallo da ruta de rexistro de Squid, comprobe tamén o percorrido de directorios e os permisos de escritura antes de atribuílo a unha etiqueta. O permiso para un servizo saínte pouco habitual é outra operación máis; os exemplos de Squid SELinux de Red Hat distinguen estes casos.
Utilice a política da distribución instalada e a guía de administración. As rutas dos paquetes, as etiquetas e o confinamento poden variar entre imaxes. En sistemas que usan AppArmor, inspeccione o seu perfil en lugar de aplicar ordes de SELinux.
Corrixa a política ou a localización implicada polas probas mentres mantén a aplicación no host. A autenticación de clientes e as regras de acceso propias de Squid seguen aplicándose despois de reparar o problema de política do host.