Diagnozi malpermesojn de Squid sub SELinux
Distingi la alirregulojn de Squid, dosierujajn permesojn, pordajn etikedojn kaj malpermesojn de la gastiga sekurpolitiko antaŭ ol ŝanĝi la devigadon.
HTTP-alirpermeso generita de Squid kaj “Permission denied” de la operaciumo okazas ĉe malsamaj limoj. Determinu ĉu Squid malfermis dosieron, ligis ingon, konektiĝis eksteren aŭ rifuzis klientan peton.
Kunligu la revizian okazaĵon
En SELinux-sistemoj, kunordigu la servan eraron kun ĝia revizia registro. La fonta domajno, cela tipo, objekta klaso kaj rifuzita permeso montras kiun operacion la politiko blokis. Ĝusta Uniksa posedeco ne pruvas, ke la sekureca etikedo taŭgas.
Propra aŭskulta pordo povas postuli la respondan pordan etikedon. Movita protokola aŭ kaŝa dosierujo povas postuli dosieran etikedadon. Por malsukceso de la protokola vojo de Squid, kontrolu ankaŭ dosierujan trairadon kaj skribajn permesojn antaŭ ol atribui ĝin al etikedo. Permeso por nekutima elira servo estas denove alia operacio; la Squid-SELinux-ekzemploj de Red Hat distingas tiujn kazojn.
Uzu la politikon de la instalita distribuo kaj la administran gvidadon. Pakejaj vojoj, etikedoj kaj limigo povas malsami inter bildoj. En sistemoj uzantaj AppArmor, inspektu ĝian profilon anstataŭ apliki SELinux-komandojn.
Korektu la politikon aŭ lokon indikitan de la pruvoj, konservante la devigadon ĉe la gastigo. La propraj klienta aŭtentikigo kaj alirreguloj de Squid ankoraŭ validas post kiam la gastiga politika problemo estas riparita.