Diagnostiquer les refus de Squid sous SELinux
Distinguez les règles d'accès de Squid, les permissions du système de fichiers, les étiquettes de port et les refus de la politique de sécurité de l'hôte avant de modifier l'application.
Un refus d'accès HTTP généré par Squid et un « Permission denied » du système d'exploitation surviennent à des frontières différentes. Déterminez si Squid ouvrait un fichier, liait une socket, se connectait vers l'extérieur ou rejetait une requête client.
Corréler l'événement d'audit
Sur les systèmes SELinux, associez l'erreur du service à son enregistrement d'audit. Le domaine source, le type cible, la classe d'objet et la permission refusée indiquent quelle opération la politique a bloquée. Une propriété Unix correcte ne prouve pas que l'étiquette de sécurité est appropriée.
Un port d'écoute personnalisé peut nécessiter l'étiquette de port correspondante. Un répertoire de journaux ou de cache déplacé peut nécessiter un étiquetage des fichiers. En cas d'échec du chemin de journal de Squid, vérifiez aussi le parcours des répertoires et les permissions d'écriture avant de l'attribuer à une étiquette. L'autorisation d'un service sortant inhabituel est encore une autre opération ; les exemples Squid SELinux de Red Hat distinguent ces cas.
Utilisez la politique de la distribution installée et les recommandations d'administration. Les chemins des paquets, les étiquettes et le confinement peuvent varier d'une image à l'autre. Sur les systèmes utilisant AppArmor, inspectez son profil au lieu d'appliquer des commandes SELinux.
Corrigez la politique ou l'emplacement mis en cause par les preuves tout en conservant l'application sur l'hôte. L'authentification des clients et les règles d'accès propres à Squid s'appliquent toujours après la réparation du problème de politique de l'hôte.