Squid-weigeringen onder SELinux diagnosticeren
Onderscheid Squid-toegangsregels, bestandssysteemmachtigingen, poortlabels en weigeringen van het beveiligingsbeleid van de host voordat u de handhaving wijzigt.
Een door Squid gegenereerde HTTP-toegangsweigering en een “Permission denied” van het besturingssysteem treden op bij verschillende grenzen. Stel vast of Squid een bestand opende, een socket bond, naar buiten verbond of een clientverzoek weigerde.
Correleer de auditgebeurtenis
Op SELinux-systemen moet u de servicefout koppelen aan het auditrecord. Het brondomein, het doeltype, de objectklasse en de geweigerde machtiging tonen welke bewerking het beleid blokkeerde. Correct Unix-eigendom bewijst niet dat het beveiligingslabel geschikt is.
Een aangepaste luisterpoort kan het bijbehorende poortlabel vereisen. Een verplaatste log- of cachemap kan bestandslabeling vereisen. Controleer bij een Squid-logpadfout ook mapdoorgang en schrijfmachtigingen voordat u het aan een label toeschrijft. Machtiging voor een ongebruikelijke uitgaande dienst is weer een andere bewerking; de Squid-SELinux-voorbeelden van Red Hat onderscheiden deze gevallen.
Gebruik het beleid van de geïnstalleerde distributie en de beheerrichtlijnen. Pakketpaden, labels en beperking kunnen per image verschillen. Onderzoek op systemen met AppArmor het profiel ervan in plaats van SELinux-opdrachten toe te passen.
Corrigeer het beleid of de locatie die het bewijs aanwijst terwijl de handhaving op de host behouden blijft. Squids eigen clientauthenticatie en toegangsregels blijven van kracht nadat het probleem met het hostbeleid is verholpen.