권한 강등 이후: 어떤 OpenVPN 파일이 여전히 작동하는가
강등 전에 열린 디스크립터는 계속 작동하지만 나중에 다시 여는 경로는 그렇지 않습니다. 세 가지 런타임 파일 중 설정이 다시 열어야 하는 것을 정하십시오.
긴 가동 시간은 그 시점에 데몬이 가진 권한으로 시작이 성공했다는 것만 증명합니다. 여기서 중요한 장애는 나중에 옵니다. 새 클라이언트가 접속하고, 폐기 목록이 교체되고, 보조 스크립트가 파일을 써야 합니다. 각각은 권한 없는 계정이 수행하는 새로운 열기이며, 고유의 권한 질문과 오류 메시지를 가집니다. 세 가지 결정이 계속 작동하는 설정과 다음 이벤트에서 실패하는 설정을 가릅니다.
일찍 읽어 들인 것과 나중에 여는 것을 구분하십시오
디스크립터는 열린 파일 기술에 대한 핸들이며, 접근 모드는 그 기술이 만들어질 때 고정됩니다. 나중에 프로세스 사용자를 바꿔도 핸들은 닫히지 않습니다. 그래서 root로 읽은 키 파일은 강등 후에도 작동합니다. 모드도 바뀌지 않습니다. 읽기용으로 연 핸들이 쓰기 가능해지지 않고, 쓰기 가능한 핸들도 계정이 경로에 대한 권리를 잃었다는 이유만으로 회수되지 않습니다. 이 두 사실이 이 보고서들의 놀라운 동작 대부분을 설명합니다.
나머지 절반은 메모리입니다. 데몬은 인증서를 분석하고 분석된 자료를 보관한 뒤 파일을 닫을 수 있습니다. 계속 쓰이는 것은 데이터이지 열린 파일이 아닙니다. 따라서 트래픽이 계속된다고 해서 디스크립터가 열려 있다거나 경로 이름에 도달할 수 있다는 것이 증명되지 않습니다. 증명되는 것은 현재 세션에 필요한 자료를 이전에 얻었다는 것뿐입니다.
나중의 열기는 다른 거래입니다. 현재 자격 증명, 현재 보안 컨텍스트, 현재 마운트 뷰 아래에서 실행되므로 시작 시 읽혔던 경로가 다음 연결에서 거부될 수 있습니다. 로테이션은 함정을 더합니다. 같은 경로 이름에 새 파일을 써도 기존 디스크립터는 옛 객체에 붙어 있습니다. 그래서 다시 읽기가 성공한 것처럼 보여도 데몬은 이전 내용을 계속 쓸 수 있습니다. 로테이션이 적용되었다고 믿기 전에 프로세스가 가진 inode와 디스크의 inode를 비교하십시오.
세 가지 런타임 읽기와 각각이 일어나는 시점을 지목하십시오
세 자원은 보통 초기화 훨씬 뒤에 열리며 서로 다른 시점에 실패합니다. 특정 클라이언트의 설정 파일은 그 클라이언트가 접속할 때 읽히므로, 다른 사용자들이 계속되는 동안 한 사람에게만 깨질 수 있습니다. 폐기 데이터는 피어 인증 중에, 그리고 파일이 교체될 때 다시 조회됩니다. 임시 디렉터리는 스크립트나 플러그인이 무언가를 쓸 때만 건드려집니다.
셋 중 어느 것도 시작 경로에 속하지 않습니다. 그래서 몇 주 동안 건강했던 서버가 다음 연결에서 실패할 수 있습니다. 이 범주는 수정의 주인도 지목합니다. 처음 둘은 데몬 계정 아래 설정에 대한 읽기 권한이고, 셋째는 목적이 좁은 쓰기 가능한 위치입니다.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key 대부분이 가정하는 것보다 좁은 질문에 답합니다. 이것은 문서화된 SIGUSR1 및 ping-restart 재설정을 넘어 키 파일을 열린 상태로 유지합니다 그리고 CCD 파일, 폐기 데이터, 보조 실행 파일, 프로세스 전체 재시작에는 아무것도 하지 않습니다. 그것들은 여전히 각자의 열기 경로를 따르며, 그 시점에 실행 중인 계정 아래에서 처리됩니다.
계정과 그것이 실제로 가진 뷰를 확인하십시오
unit 파일을 믿는 대신 실행 중인 데몬에 어떤 계정을 쓰는지 물어보고, 그 답을 unit이 설정한 것과 비교하십시오. 불일치는 가장 먼저 풀 문제입니다. 이후의 모든 권한 검사는 프로세스가 실제로 누구인지의 자격으로 실행되기 때문입니다. 그다음 경로를 구성 요소별로 따라가십시오. 통과는 각 계층에서 평가되므로 통과할 수 없는 디렉터리 안의 읽을 수 있는 파일은 여전히 읽을 수 없습니다. 최종 파일 모드는 마지막 질문이지 첫 질문이 아닙니다.
네임스페이스와 서비스 샌드박스는 소유권과 모드 비트가 설명하지 않는 경계를 더합니다. 셸에서 보이는 경로가 chroot, 마운트 네임스페이스, 또는 홈 디렉터리를 숨기는 unit 안에서는 없거나 읽기 전용일 수 있습니다. 보안 모듈이 한 겹 더하므로 읽을 수 있어 보이는 파일도 열 때 거부될 수 있습니다.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/alice관리자 셸에서의 성공적인 읽기는 그 결합된 조건을 하나도 시험하지 않습니다. 데몬 계정으로, 같은 네임스페이스와 샌드박스를 갖고 검사를 실행하거나, 결과가 서버가 아니라 당신의 셸을 설명한다는 것을 받아들이십시오. 세 번째 명령은 그 시험의 저렴한 판입니다. 각 구성 요소의 모드를 출력하고 데몬 계정이 통과할 수 없는 첫 요소에서 실패합니다.
런타임 쓰기에는 전용 디렉터리를 주십시오
읽기는 목록의 절반에 불과합니다. 보조 스크립트가 상태 파일을 만들어야 하고, 플러그인이 설정 옆에 상태를 써야 할 수 있습니다. 그런 쓰기는 설정 트리를 쓰기 가능하게 만든다고 덮이지 않습니다. 해당 기능이 요구하는 쓰기 권한을 특정 디렉터리에 주고, 설명할 수 있는 소유자와 모드를 붙이십시오. 읽기만 하는 모든 것에는 읽기 전용 접근을 선호하십시오.
개인 키의 권한은 정책 파일과 분리해 두십시오. 재설정 후 다시 읽어야 하는 키는 연결마다 읽는 클라이언트 파일과 요구가 다르며, 둘에 하나의 느슨한 모드를 주면 문제가 요구하는 것보다 많은 접근을 넘깁니다. 소유권을 좁힌 전용 데몬 계정은 넓은 그룹보다 감사하기 쉽습니다. 키가 재설정을 견뎌야 할 때, persist-key 디렉터리를 넓히는 대신 다시 읽기를 없앱니다.
재현할 수 있는 이벤트로 판단하십시오
살아 있는 터널은 코드를 지나는 하나의 경로만 증명합니다. 파일이 필요한 이벤트가 당신이 관심 있는 열기를 덮는 유일한 시험입니다. 새 클라이언트 연결이든, 교체된 폐기 파일이든, 허용된 소프트 재설정이든, 계획된 재시작이든 마찬가지입니다. 이벤트를 고르고 실행하고, 마지막이 아니라 첫 오류를 남기십시오.
소프트 재설정에서는 신호 하나와 unit의 로그가 키를 다시 읽었는지 보여 줍니다. 신호를 보낸 뒤 unit이 쓴 마지막 줄을 읽으십시오.
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pager권한이 내려갔다는 이유만으로 침해된 데몬이 더 이상 파일을 바꿀 수 없다고 결론 내지 마십시오. 남은 자격 증명, 능력, 쓸 수 있는 디렉터리, 아직 들고 있는 쓰기 가능한 디스크립터에 따라 달라집니다. 권한 축소는 권한의 범위를 좁히고, 런타임 열기 목록이 그 정도를 보여 줍니다. 그 경계를 설정 옆에 적어 두면 다음 사람이 다시 발견할 필요가 없습니다.