터미널의 root, SELinux 아래에서 거부됨: 훅이 실패하는 이유

up 스크립트를 root로 실행하면 완료되지만, 서비스가 같은 스크립트를 호출하면 실패합니다. 파일 권한은 아무것도 바뀌지 않았으므로 다음에 자연스럽게 권한을 다시 풀게 되지만, 그것으로는 아무것도 고쳐지지 않습니다. SELinux 호스트에서 결정적인 요인은 프로세스가 누구인지가 아니라 어느 도메인에서 실행되는지인 경우가 많고, 제한된 도메인 안의 root도 여전히 제한됩니다.

같은 명령, 두 개의 서로 다른 보안 도메인

유형 강제는 소스 도메인과 대상 레이블, 요청된 작업을 함께 평가합니다. 터미널 세션은 제한 없는 또는 관리용 도메인에서 실행되고, 데몬은 해당 유닛에 할당된 도메인에서 실행됩니다. 그래서 동일한 명령이 서로 다른 결정을 낳고, 그 차이는 정책의 버그가 아니라 의도된 것입니다.

그래서 두 실행의 비교는 그 문맥을 비교할 때만 유용합니다. 같은 명령을 셸에서도 훅에서도 실행해 보면, 셸 버전은 바이너리가 존재하고 인자가 올바르다는 것을 증명하지만, 서비스에 실행 권한이 있는지는 아무것도 증명하지 않습니다. 두 방법으로 모두 실행하고 종료 코드만이 아니라 도메인을 비교하세요. 그 비교가 모호한 권한 불만을 하나의 도메인과 하나의 레이블에 대한 구체적인 질문으로 바꿉니다.

이 결함의 전형적인 형태는 외부 도구를 호출하는 도우미입니다. 훅 자체는 허용될 수 있지만, 호출하는 도구가 서비스 도메인이 실행할 수 없는 레이블을 지니거나, 레이블이 금지하는 디렉터리에 씁니다.

훅 오류 옆의 AVC 레코드를 읽으세요

AVC 거부는 사안을 결정하는 필드를 지목합니다: 프로세스의 소스 컨텍스트, 객체의 대상 컨텍스트, 객체 클래스, 그리고 거부된 특정 권한입니다. 실행에 대한 거부와 쓰기에 대한 거부는 수리가 전혀 다르므로 이론을 세우기 전에 네 가지를 모두 읽으세요.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

소스 컨텍스트는 서비스가 실제로 실행되는 도메인과, 대상 컨텍스트는 작업이 건드린 파일이나 디렉터리의 레이블과 일치해야 합니다. 둘 중 하나라도 추적 중인 오류와 맞지 않으면 다른 이벤트를 읽고 있는 것입니다.

레코드 옆에 정책 버전과 실행 파일의 정확한 경로를 적어 두세요. 한 배포판의 정책에 나오는 도메인 이름은 그 설치에 대한 증거이며, 다른 빌드가 같은 규칙을 제공한다는 보장은 아닙니다. 이 문맥이 있어야 다른 사람이 자기 호스트에서 당신의 결론을 재현할 수 있습니다. 그것이 없으면 레코드는 증거가 아니라 일화로 읽힙니다.

레이블, 구성, 정책: 세 가지 수리

첫 번째 수리는 파일의 설치 위치와 맞지 않는 레이블입니다. cp로 제자리에 복사했거나 편집기로 작성한 스크립트는 서비스 도메인이 쓸 수 없는 기본 레이블을 가질 수 있고, 예상 컨텍스트를 복원하면 정책을 전혀 건드리지 않고 고쳐집니다.

두 번째는 구성입니다. 배포판이 작업을 실행하는 지원되는 방법, 도우미를 위한 문서화된 디렉터리, 또는 이미 이를 허용하는 갱신된 정책 패키지를 제공할 수 있습니다. 레이아웃을 지원되는 방식으로 바꾸는 것이 정책을 쓰는 것보다 싸고 업데이트에서도 살아남습니다.

세 번째는 정말로 빠진 규칙이며 마지막 수단이어야 합니다. 감사 도구로 후보를 생성하고, 실제로 무엇을 허용하는지 읽고, 관찰한 작업과 도메인으로 좁히고, 프로덕션에 가까워지기 전에 다른 사람의 검토를 받으세요.

오래된 allow 모듈이 답이 아닌 이유

이 결함의 검색 결과는 미리 만들어진 모듈로 가득하며, 흔히 훅이 더 이상 호출하지 않는 도구를 위한 것입니다. 하나를 설치하면 당신의 거부와 무관할 수 있는 권한이 부여되고, 영구적인 구멍을 추가하면서 실제 불일치는 그대로 둡니다.

다음 실패도 감춥니다. 넓은 부류의 작업을 허용하는 모듈은 이 오류를 사라지게 하고 다음 오류를 훨씬 귀속시키기 어려운 것으로 바꿉니다. 나중에 모듈을 제거하는 것도 아무도 일정에 넣고 싶지 않은 변경이라, 지름길은 영구적이 되기 쉽습니다.

규율 있는 비교는 당신이 읽을 수 있는 거부와 당신이 제안하는 변경 사이의 비교입니다. Red Hat의 SELinux 문제 해결 안내서 는 바로 이 이유로 레이블과 구성 점검을 생성된 정책보다 앞에 둡니다. 레코드에 해당하는 거부가 없다면 SELinux는 아마 당신의 문제가 아니며, 경로, 샌드박스, 권한 문제는 여전히 열려 있습니다.