Diagnosticarea refuzurilor Squid sub SELinux
Distingeți regulile de acces ale Squid, permisiunile sistemului de fișiere, etichetele porturilor și refuzurile politicii de securitate a gazdei înainte de a schimba aplicarea.
Un refuz de acces HTTP generat de Squid și un “Permission denied” al sistemului de operare apar la limite diferite. Stabiliți dacă Squid deschidea un fișier, lega un socket, se conecta spre exterior sau respingea o cerere a clientului.
Corelați evenimentul de audit
Pe sistemele SELinux, potriviți eroarea serviciului cu înregistrarea sa de audit. Domeniul sursă, tipul țintă, clasa obiectului și permisiunea refuzată arată ce operațiune a blocat politica. Proprietatea Unix corectă nu dovedește că eticheta de securitate este adecvată.
Un port de ascultare personalizat poate necesita eticheta de port corespunzătoare. Un director de jurnale sau de cache mutat poate necesita etichetarea fișierelor. Pentru o eroare a căii de jurnal a Squid, verificați și parcurgerea directoarelor și permisiunile de scriere înainte de a o atribui unei etichete. Permisiunea pentru un serviciu de ieșire neobișnuit este din nou altă operațiune; exemplele Squid SELinux de la Red Hat disting aceste cazuri.
Folosiți politica distribuției instalate și îndrumările administrative. Căile pachetelor, etichetele și izolarea pot varia între imagini. Pe sistemele care folosesc AppArmor, inspectați profilul acestuia în loc să aplicați comenzi SELinux.
Corectați politica sau locația indicată de dovezi, păstrând aplicarea pe gazdă. Autentificarea clienților și regulile de acces proprii ale Squid se aplică în continuare după remedierea problemei de politică a gazdei.