Diagnosticare i rifiuti di Squid sotto SELinux
Distinguere le regole di accesso di Squid, i permessi del filesystem, le etichette delle porte e i rifiuti della politica di sicurezza dell'host prima di modificare l'applicazione.
Un rifiuto di accesso HTTP generato da Squid e un “Permission denied” del sistema operativo si verificano a confini diversi. Stabilire se Squid stava aprendo un file, vincolando un socket, connettendosi verso l'esterno o rifiutando una richiesta del client.
Correlare l'evento di audit
Sui sistemi SELinux, associare l'errore del servizio al relativo record di audit. Il dominio di origine, il tipo di destinazione, la classe dell'oggetto e il permesso negato mostrano quale operazione è stata bloccata dalla politica. Una corretta proprietà Unix non dimostra che l'etichetta di sicurezza sia adeguata.
Una porta di ascolto personalizzata può richiedere l'etichetta di porta corrispondente. Una directory di log o cache spostata può richiedere l'etichettatura dei file. Per un errore del percorso di log di Squid, controllare anche il attraversamento delle directory e i permessi di scrittura prima di attribuirlo a un'etichetta. Il permesso per un servizio in uscita insolito è ancora un'altra operazione; gli esempi Squid SELinux di Red Hat distinguono questi casi.
Usare la politica della distribuzione installata e le indicazioni amministrative. I percorsi dei pacchetti, le etichette e il confinamento possono variare tra le immagini. Sui sistemi che usano AppArmor, ispezionare il suo profilo invece di applicare comandi SELinux.
Correggere la politica o la posizione indicata dalle prove mantenendo l'applicazione sull'host. L'autenticazione dei client e le regole di accesso di Squid continuano ad applicarsi dopo la riparazione del problema di politica dell'host.