VPN 인증서를 옮기면 SELinux 레이블이 깨지는 이유

인증서가 올바른 디렉터리에 읽을 수 있는 모드와 root 소유로 있어도 서비스는 파일을 열 수 없다고 보고할 수 있습니다. SELinux 시스템에서 이 조합은 권한이 아니라 특정 메커니즘을 가리킵니다. 레이블이 파일과 함께 이동한 것은 이름 변경이 새 객체를 만들지 않기 때문입니다. inode는 이전 경로에서 가졌던 보안 컨텍스트를 유지했고, 새 경로의 정책은 자신의 컨텍스트를 할당할 기회를 얻지 못했습니다.

이름 변경이 실제로 레이블에 하는 일

파일은 SELinux 컨텍스트를 inode에 붙은 속성 데이터로 지니며, 같은 파일 시스템 안에서 이름을 바꾸면 디렉터리 항목만 바뀌고 그 밖에는 아무것도 바뀌지 않습니다. 이것이 빠르고 원자적이며, 컨텍스트가 이동을 견디는 이유입니다. 어떤 정책도 조회되지 않고, 어떤 기본값도 적용되지 않으며, 어떤 경고도 출력되지 않습니다.

복사는 다르게 동작하는데, 복사본은 대상 디렉터리에 새 inode를 만들고 정책은 그 디렉터리의 유형에서 컨텍스트를 할당합니다. 그래서 복사한 인증서는 보통 올바른 레이블을 얻지만 옮긴 인증서는 잘못된 채로 남습니다. 이 하나의 차이가 이런 종류의 티켓에서 나오는 혼란의 대부분을 설명합니다.

파일 시스템 간 이동은 복사 의미론으로 되돌아가므로, 같은 명령이라도 /etc이 자체 볼륨에 있는지에 따라 두 머신에서 다르게 동작할 수 있습니다. 도구가 신뢰할 수 없다고 결론내리기 전에 이것을 확인하세요. 마운트 테이블을 한 번 보면 어떤 종류의 이동을 했는지 알 수 있습니다.

현재 레이블을 기대되는 레이블과 읽어 보세요

읽기 전용 명령 세 가지가 아무것도 바꾸지 않고 이 질문에 답합니다. 첫 번째는 파일이 지금 무엇을 가졌는지 보여 주고, 두 번째는 그 정확한 경로에 대해 정책이 무엇을 기대하는지 알려 주며, 세 번째는 디렉터리 아래에서 레이블이 다른 모든 파일을 나열합니다.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

신뢰할 것은 드라이 런으로, 정책에서 벗어난 컨텍스트를 가진 모든 파일을 지목하면서도 시스템은 건드리지 않기 때문입니다. 인증서가 그 목록에 나타나면 경로가 의미하는 것과 파일이 주장하는 것 사이의 불일치를 찾은 것입니다. 나타나지 않으면 레이블은 이미 정책이 원하는 것이고 당신의 시간은 다른 곳에 속합니다.

그다음 그 차이를 실제 거부와 연결하세요. 불일치는 잘못된 레이블의 증거이지 서비스가 그 때문에 실패했다는 증명이 아니며, 로그에 대응하는 거부 없이 적용한 수정은 단계만 늘린 추측입니다.

예외를 만들어 내는 대신 매핑을 복원하세요

표준 위치라면 정책이 이미 경로를 매핑하므로 restorecon이 그것을 적용하면 작업이 끝납니다. 범위는 고치는 디렉터리로 한정하고, 파일 시스템 전체를 다시 레이블링하는 것은 느리고 방해가 되며 원래 실수를 아주 큰 변경 아래 묻어 버립니다.

사용자 지정 디렉터리에서는 순서가 중요하며, 순서를 뒤집으면 아무것도 바꾸지 않으면서 성공을 보고하는 명령이 됩니다. 매핑은 정책에, 다시 레이블링은 마지막에, 드라이 런은 둘 모두 앞에 속합니다. 그 마지막 부분을 건너뛰는 것이 한 번도 잘못된 적 없는 경로를 그래도 다시 레이블링하게 되는 방식입니다.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon은 매핑을 적용하지만 매핑을 만들어 내지는 못합니다. 경로를 설명하는 규칙이 없으면 복원할 원본이 없고, 그래서 영구 매핑이 다시 레이블링 전에 존재해야 합니다. 그렇지 않으면 이후의 이동, 패키지 업데이트, 다시 레이블링이 결함을 다시 만들고 다음 사람이 처음부터 시작하므로, 어느 구성이 그 매핑을 소유하는지 기록하세요.

chcon이 해결책이 아닌 이유

chcon은 컨텍스트를 파일에 직접 쓰며, 즉시 적용되지만 사용 가능한 옵션 중 가장 오래가지 않습니다. 파일 시스템 다시 레이블링은 정책을 다시 적용하고 묻지도 않고 수동 변경을 버리기 때문입니다. 파일은 고쳐진 것처럼 보이고 그 수정에는 아무도 적어 두지 않은 유효 기간이 있습니다. 대신 필요한 것은 경로를 설명하는 규칙이며, 그래야 그곳에 도착하는 모든 파일이 자동으로 같은 처리를 받습니다.

더 나쁘게도, 근본 매핑이 여전히 없으므로 결함은 몇 주 뒤에 뚜렷한 방아쇠도, 그 우회책에 대한 기억도 없이 돌아오는 잘못된 교훈을 줍니다. chcon은 가설을 확인하기 위한 임시 실험으로만 쓰고, 그다음에는 다음 다시 레이블링을 견디는 매핑으로 바꾸고, 교체가 실제로 자리 잡았는지 확인하세요.

레이블이 올바른데 접근이 여전히 실패할 때

상위 디렉터리부터 시작하세요. 통과 권한은 경로의 모든 구성 요소에서 검사되므로, 서비스가 들어갈 수 없는 디렉터리 안의 올바르게 레이블된 인증서도 읽을 수 없습니다. SELinux와 일반 권한 모두 각 단계를 허용해야 하며, 하나를 고쳐도 다른 하나는 고쳐지지 않습니다.

다음으로 프로세스 신원과 서비스 자체의 샌드박싱을 확인하세요. 제한적인 샌드박스를 가진 유닛은 정책이 기꺼이 허용할 파일에 대한 접근을 거부할 수 있고, 로그 줄에서는 두 원인이 똑같아 보입니다. 실제로 어느 프로세스가 묻고 있는지 확인하고, 당신이 묻고 있다고 가정하는 프로세스를 확인하지 마세요.

dontaudit 규칙이 거부 메시지를 억제할 수 있으므로 빈 감사 로그는 증명이 아니라 약한 증거입니다. 정책이 옳아 보이는데도 접근이 실패하면 넓은 허용 모듈을 생성하기 전에 조사하고, 증상을 없애기 위해 SELinux를 끄지 마세요. 두 지름길 모두 작동하는 것처럼 보이는 시스템과 아무도 설명할 수 없는 보안 태세를 만듭니다. 짧은 조사가 둘 중 어느 것보다 낫습니다.