SELinux 환경에서 Squid 거부 진단

Squid가 생성하는 HTTP 액세스 거부와 운영 체제의 “Permission denied”는 서로 다른 경계에서 발생합니다. Squid가 파일을 열고 있었는지, 소켓을 바인딩하고 있었는지, 외부로 연결하고 있었는지, 클라이언트 요청을 거부하고 있었는지 판별합니다.

감사 이벤트 상호 연관

SELinux 시스템에서는 서비스 오류를 해당 감사 레코드와 대조합니다. 소스 도메인, 대상 유형, 객체 클래스, 거부된 권한은 정책이 어떤 작업을 차단했는지 보여 줍니다. 올바른 Unix 소유권이 보안 레이블이 적절하다는 것을 증명하지는 않습니다.

사용자 지정 수신 포트에는 해당 포트 레이블이 필요할 수 있습니다. 이동한 로그나 캐시 디렉터리에는 파일 레이블 지정이 필요할 수 있습니다. Squid 로그 경로 실패의 경우 레이블 탓으로 돌리기 전에 디렉터리 탐색과 쓰기 권한도 확인하십시오. 비정상적인 아웃바운드 서비스에 대한 권한은 또 다른 작업입니다. Red Hat의 Squid SELinux 예시는 이러한 경우를 구분합니다.

설치된 배포판의 정책과 관리 지침을 사용합니다. 패키지 경로, 레이블, 격리는 이미지마다 다를 수 있습니다. AppArmor를 사용하는 시스템에서는 SELinux 명령을 적용하는 대신 해당 프로필을 검사합니다.

증거가 지시하는 정책이나 위치를 수정하되 호스트의 적용은 유지합니다. 호스트 정책 문제를 해결한 뒤에도 Squid 자체의 클라이언트 인증과 액세스 규칙은 계속 적용됩니다.