Squid-weierings onder SELinux diagnose stel
Onderskei Squid-toegangsreëls, lêerstelseltoestemmings, poortetikette en weierings deur die gasheersekuriteitsbeleid voordat jy die afdwinging verander.
'n HTTP-toegangsweiering wat deur Squid gegenereer word en 'n bedryfstelsel se “Permission denied” vind by verskillende grense plaas. Stel vas of Squid 'n lêer oopgemaak het, 'n socket gebind het, uitwaarts verbind het of 'n kliëntversoek verwerp het.
Korreleer die ouditgebeurtenis
Op SELinux-stelsels, pas die diensfout by sy ouditrekenaar. Die brondomein, teikentipe, objekklas en die geweierde toestemming wys watter bewerking deur die beleid geblokkeer is. Korrekte Unix-eienaarskap bewys nie dat die sekuriteitsetiket gepas is nie.
'n Pasgemaakte luisterpoort kan die ooreenstemmende poortetiket vereis. 'n Verskuifde log- of kasgids kan lêeretikettering vereis. Vir 'n Squid-logpadfout, kyk ook na gidsdeurgang en skryftoestemmings voordat jy dit aan 'n etiket toeskryf. Toestemming vir 'n ongewone uitwaartse diens is weer 'n ander bewerking; Red Hat se Squid-SELinux-voorbeelde onderskei hierdie gevalle.
Gebruik die geïnstalleerde verspreiding se beleid en administrasieleiding. Pakketpaaie, etikette en inperking kan tussen beelde verskil. Op stelsels wat AppArmor gebruik, ondersoek die profiel daarvan eerder as om SELinux-opdragte toe te pas.
Korrigeer die beleid of ligging wat deur die bewyse geïmpliseer word, terwyl gasherafdwinging behou word. Squid se eie kliëntverifikasie en toegangsreëls geld steeds nadat die gasheersbeleidprobleem herstel is.