Diagnostikimi i refuzimeve të Squid nën SELinux
Bëni dallimin midis rregullave të aksesit të Squid, lejeve të sistemit të skedarëve, etiketave të porteve dhe refuzimeve të politikës së sigurisë së hostit përpara se të ndryshoni zbatimin.
Një refuzim i aksesit HTTP i krijuar nga Squid dhe një “Permission denied” i sistemit operativ ndodhin në kufij të ndryshëm. Përcaktoni nëse Squid po hapte një skedar, po lidhte një socket, po lidhej nga jashtë ose po refuzonte një kërkesë klienti.
Lidhni ngjarjen e auditimit
Në sistemet SELinux, përputhni gabimin e shërbimit me regjistrin e auditimit të tij. Domeni burimor, lloji i synuar, klasa e objektit dhe leja e refuzuar tregojnë se cilën operacion bllokoi politika. Pronësia e saktë në Unix nuk provon se etiketa e sigurisë është e përshtatshme.
Një port dëgjimi i personalizuar mund të kërkojë etiketën përkatëse të portit. Një drejtori regjistrash ose cache e zhvendosur mund të kërkojë etiketim skedarësh. Për një dështim të rrugës së regjistrit të Squid, kontrolloni gjithashtu kalimin nëpër drejtori dhe lejet e shkrimit përpara se t'ia atribuoni një etikete. Leja për një shërbim dalës të pazakontë është përsëri një operacion tjetër; shembujt Squid SELinux të Red Hat i dallojnë këto raste.
Përdorni politikën e shpërndarjes së instaluar dhe udhëzimet administrative. Rrugët e paketave, etiketat dhe kufizimi mund të ndryshojnë midis imazheve. Në sistemet që përdorin AppArmor, inspektoni profilin e tij në vend që të aplikoni komanda SELinux.
Korrigjoni politikën ose vendndodhjen e treguar nga provat duke ruajtur zbatimin në host. Vërtetimi i klientëve dhe rregullat e aksesit të vetë Squid vazhdojnë të zbatohen pas rregullimit të problemit të politikës së hostit.