Diagnosticar les denegacions de Squid sota SELinux
Distingiu les regles d'accés de Squid, els permisos del sistema de fitxers, les etiquetes de port i les denegacions de la política de seguretat de l'amfitrió abans de canviar l'aplicació.
Una denegació d'accés HTTP generada per Squid i un “Permission denied” del sistema operatiu es produeixen en límits diferents. Determineu si Squid obria un fitxer, enllaçava un sòcol, connectava cap a fora o rebutjava una petició de client.
Correlacioneu l'esdeveniment d'auditoria
En sistemes SELinux, feu coincidir l'error del servei amb el seu registre d'auditoria. El domini d'origen, el tipus de destinació, la classe d'objecte i el permís denegat mostren quina operació va bloquejar la política. La propietat correcta a Unix no demostra que l'etiqueta de seguretat sigui adequada.
Un port d'escolta personalitzat pot requerir l'etiqueta de port corresponent. Un directori de registres o de memòria cau reubicat pot requerir etiquetatge de fitxers. Per a una fallada de la ruta de registre de Squid, comproveu també el recorregut de directoris i els permisos d'escriptura abans d'atribuir-la a una etiqueta. El permís per a un servei de sortida inusual és una altra operació; els exemples de Squid SELinux de Red Hat distingeixen aquests casos.
Utilitzeu la política de la distribució instal·lada i la guia d'administració. Les rutes dels paquets, les etiquetes i el confinament poden variar entre imatges. En sistemes que utilitzen AppArmor, inspeccioneu-ne el perfil en lloc d'aplicar ordres de SELinux.
Corregiu la política o la ubicació implicada per les proves mantenint l'aplicació a l'amfitrió. L'autenticació de clients i les regles d'accés pròpies de Squid continuen aplicant-se després de reparar el problema de política de l'amfitrió.