Diagnosticering af Squid-afvisninger under SELinux
Skeln mellem Squids adgangsregler, filsystemtilladelser, portmærker og værtens sikkerhedspolitikafvisninger, før du ændrer håndhævelsen.
En HTTP-adgangsafvisning genereret af Squid og operativsystemets “Permission denied” opstår ved forskellige grænser. Afgør, om Squid åbnede en fil, bandt en socket, forbandt udad eller afviste en klientanmodning.
Korrelér revisionshændelsen
På SELinux-systemer skal du matche tjenestefejlen med dens revisionspost. Kildedomænet, måltypen, objektklassen og den afviste tilladelse viser, hvilken handling politikken blokerede. Korrekt Unix-ejerskab beviser ikke, at sikkerhedsmærket er passende.
En brugerdefineret lytteport kan kræve det tilsvarende portmærke. En flyttet log- eller cachemappe kan kræve filmærkning. Ved en Squid-logstifejl skal du også kontrollere mappegennemgang og skrivetilladelser, før du tilskriver det et mærke. Tilladelse til en usædvanlig udgående tjeneste er igen en anden handling; Red Hats Squid SELinux-eksempler skelner mellem disse tilfælde.
Brug den installerede distributions politik og administrationsvejledning. Pakkestier, mærker og indeslutning kan variere mellem images. På systemer med AppArmor skal du undersøge dens profil i stedet for at anvende SELinux-kommandoer.
Ret den politik eller placering, som evidensen peger på, mens værtshåndhævelsen bevares. Squids egen klientgodkendelse og adgangsregler gælder stadig, efter at værtsproblemet er udbedret.