Diagnostisere Squid-avvisninger under SELinux
Skill mellom Squids tilgangsregler, filsystemtillatelser, portetiketter og vertens sikkerhetspolicyavvisninger før du endrer håndhevelsen.
En HTTP-tilgangsavvisning generert av Squid og operativsystemets “Permission denied” oppstår ved forskjellige grenser. Avgjør om Squid åpnet en fil, bandt en socket, koblet utover eller avviste en klientforespørsel.
Korreler revisjonshendelsen
På SELinux-systemer må du matche tjenestefeilen med revisjonsoppføringen. Kildedomenet, måltypen, objektklassen og den avviste tillatelsen viser hvilken operasjon policyen blokkerte. Korrekt Unix-eierskap beviser ikke at sikkerhetsetiketten er passende.
En tilpasset lyttport kan kreve den tilsvarende portetiketten. En flyttet logg- eller hurtigbufferkatalog kan kreve filmerking. Ved en Squid-loggbanefeil, sjekk også kataloggjennomgang og skrivetillatelser før du tilskriver det en etikett. Tillatelse for en uvanlig utgående tjeneste er igjen en annen operasjon; Red Hats Squid SELinux-eksempler skiller disse tilfellene.
Bruk policyen til den installerte distribusjonen og administrasjonsveiledningen. Pakkebane, etiketter og inneslutning kan variere mellom bilder. På systemer med AppArmor, undersøk profilen i stedet for å bruke SELinux-kommandoer.
Rett policyen eller plasseringen som bevisene peker på, mens håndhevelsen på verten beholdes. Squids egen klientautentisering og tilgangsregler gjelder fortsatt etter at vertspolicyproblemet er rettet.