Squid-Ablehnungen unter SELinux diagnostizieren
Unterscheiden Sie Squid-Zugriffsregeln, Dateisystemberechtigungen, Portlabels und Ablehnungen der Host-Sicherheitsrichtlinie, bevor Sie die Durchsetzung ändern.
Eine von Squid erzeugte HTTP-Zugriffsablehnung und ein “Permission denied” des Betriebssystems treten an unterschiedlichen Grenzen auf. Stellen Sie fest, ob Squid eine Datei öffnete, einen Socket band, nach außen verband oder eine Client-Anfrage ablehnte.
Das Audit-Ereignis korrelieren
Ordnen Sie auf SELinux-Systemen den Dienstfehler seinem Audit-Datensatz zu. Quelldomäne, Zieltyp, Objektklasse und verweigerte Berechtigung zeigen, welche Operation die Richtlinie blockiert hat. Korrekte Unix-Eigentümerschaft belegt nicht, dass das Sicherheitslabel geeignet ist.
Ein benutzerdefinierter Listening-Port kann das entsprechende Portlabel erfordern. Ein verschobenes Log- oder Cache-Verzeichnis kann eine Dateikennzeichnung erfordern. Prüfen Sie bei einem Squid-Logpfadfehler zusätzlich Verzeichnisdurchquerung und Schreibberechtigungen, bevor Sie ihn einem Label zuschreiben. Die Berechtigung für einen ungewöhnlichen ausgehenden Dienst ist wieder eine andere Operation; die Squid-SELinux-Beispiele von Red Hat unterscheiden diese Fälle.
Verwenden Sie die Richtlinie der installierten Distribution und die Administrationshinweise. Paketpfade, Labels und Einschränkung können sich zwischen Images unterscheiden. Untersuchen Sie auf Systemen mit AppArmor dessen Profil, statt SELinux-Befehle anzuwenden.
Korrigieren Sie die durch die Belege bezeichnete Richtlinie oder den Ort, während die Durchsetzung auf dem Host erhalten bleibt. Squids eigene Client-Authentifizierung und Zugriffsregeln gelten weiterhin, nachdem das Host-Richtlinienproblem behoben ist.