Diagnostisera Squid-nekanden under SELinux
Skilj mellan Squids åtkomstregler, filsystembehörigheter, portetiketter och värdenes säkerhetspolicynekanden innan du ändrar verkställigheten.
Ett HTTP-åtkomstnekande som Squid genererar och operativsystemets “Permission denied” inträffar vid olika gränser. Avgör om Squid öppnade en fil, band en socket, anslöt utåt eller avvisade en klientbegäran.
Korrelera granskningshändelsen
På SELinux-system ska du matcha tjänstefelet mot dess granskningspost. Källdomänen, måltypen, objektklassen och den nekade behörigheten visar vilken åtgärd policyn blockerade. Korrekt Unix-ägande bevisar inte att säkerhetsetiketten är lämplig.
En anpassad lyssnarport kan kräva motsvarande portetikett. En flyttad logg- eller cachekatalog kan kräva filmärkning. Vid ett Squid-loggvägsfel, kontrollera även kataloggenomgång och skrivbehörigheter innan du tillskriver det en etikett. Behörighet för en ovanlig utgående tjänst är återigen en annan åtgärd; Red Hats Squid SELinux-exempel skiljer dessa fall.
Använd den installerade distributionens policy och administrationsvägledning. Paketvägar, etiketter och isolering kan variera mellan avbildningar. På system med AppArmor, granska dess profil i stället för att tillämpa SELinux-kommandon.
Rätta policyn eller platsen som bevisen pekar på medan verkställigheten på värden behålls. Squids egen klientautentisering och åtkomstregler gäller fortfarande efter att värdenes policyproblem åtgärdats.