systemd 강화를 OpenVPN의 user 드롭 위에 겹치지 마십시오

최소 권한 레시피 두 개를 붙여 놓는다고 더 엄격한 배포가 되지는 않습니다. 한 모델은 데몬이 권한을 가지고 시작해 초기화 후 비특권 계정으로 내려가게 합니다. 다른 모델은 서비스 관리자가 첫 명령부터 제한된 신원으로 실행하게 합니다. 각각은 단독으로 동작하지만, 결합하면 두 작업 중 어느 것도 깔끔하게 해내지 못하는 서비스가 되기 쉽습니다. 나머지는 이 결정을 순서대로 짚어 갑니다.

두 모델, 전환의 주인은 하나

첫 번째 모델은 데몬의 것입니다. 커뮤니티 OpenVPN의 user 와 group 옵션은 터널과 키가 설정된 뒤 신원을 바꾸고, persist-key 와 persist-tun 는 그 자원을 이후에도 쓸 수 있게 유지합니다.

두 번째 모델은 서비스 관리자의 것입니다. systemd의 User= 또는 Group= 설정이 프로세스가 어느 신원으로 시작하는지 정하고, 케이퍼빌리티 지시문이 무엇을 보유할 수 있는지 정합니다. 두 모델 중 무엇을 고를지는 보안 문제이기 전에 패키징 문제이며, 패키지 관리자는 이미 답을 냈습니다. 여러분의 일은 세 번째 선택지를 만드는 것이 아니라 그 답을 찾는 것입니다.

둘 다 정당합니다. 실수는 이들을 한 설계의 층으로 취급하는 것입니다. 두 번째 모델은 첫 번째 모델의 신원 전환을 프로세스가 더는 허용되지 않는 작업으로 만들 수 있습니다.

신원이 어디서 바뀌는지 정하십시오

유닛이 이미 전용 계정으로 시작한다면, 데몬에게 다른 계정이 되라고 지시하는 것은 강화된 서비스가 해서는 안 되는 setuid 전환을 요구하는 것입니다. 실패는 시작 시 권한 오류로 나타나지, 분명한 정책 메시지로 나타나지 않습니다. 이것은 빠진 케이퍼빌리티처럼 읽힙니다, 그래서 사람들은 신원 문제가 아니라 더 넓은 경계 집합 쪽으로 밀려납니다.

무엇이든 편집하기 전에 설치된 패키지가 실제로 무엇을 제공하는지 읽으십시오. drop-in 디렉터리도 포함해서요. 일부 유닛은 관리자가 이미 처리하므로 데몬 자체의 하강을 일부러 생략하고, 일부는 초기화 후 전환을 그 옵션에 의존합니다. 어떤 모델을 물려받았는지 모른 채 둘 중 하나를 제거하는 것이 작동하던 서비스가 시작하지 않게 되는 방식입니다.

고른 모델을 한 줄로 쓰십시오. 관리자 소유인지 데몬 소유인지. 이후의 모든 지시문은 그 문장과 일치해야 하고, 혼합된 유닛은 타협이 아니라 결함으로 취급해야 합니다.

케이퍼빌리티는 상한이지 부여가 아닙니다

케이퍼빌리티 경계 집합은 프로세스가 최대로 무엇을 보유할 수 있는지 말합니다. 그것은 천장이고, 거기에 케이퍼빌리티를 나열해도 그 자체로는 아무것도 주지 않습니다. 그래서 경계 집합이 넉넉한 유닛도 터널을 만들지 못할 수 있습니다.

케이퍼빌리티를 실제로 서비스의 앰비언트 집합에 넣는 것은 AmbientCapabilities= 입니다. systemd 실행 레퍼런스는 두 지시문을 따로 문서화하며, 이 구분이 온라인에서 케이퍼빌리티에 관한 혼란스러운 조언 대부분을 설명합니다.

케이퍼빌리티는 실패하는 작업이 그것을 확인한 뒤에만 추가하십시오. 더 넓은 경계 집합은 진짜 원인을 가리고 서비스를 설계 의도보다 더 많은 권한으로 남깁니다. 천장이 더는 작업을 설명하지 않으므로 유닛 검토도 어려워집니다. 실제 결함이 고쳐지면 여분의 케이퍼빌리티를 제거하십시오.

권한을 수명 주기 전체에 매핑하십시오

각 단계에서 프로세스가 무엇을 해야 하는지 나열하십시오. 시작, 정상 상태, 재인증, 그리고 해체입니다. 인터페이스 생성, 경로 변경, 보호된 키 읽기, 헬퍼 호출이 모두 같은 순간에 또는 같은 요구 아래 일어나지는 않습니다. 케이퍼빌리티로 정렬하기 전에 단계로 정렬하십시오.

지속성 옵션은 재협상에 걸쳐 자원을 보존하지만, 애초에 없던 권한을 주지는 않습니다. 시작 시 프로세스가 읽을 수 없는 키는 지속성 플래그가 무슨 말을 하든 나중에도 읽을 수 없습니다. 플래그는 이미 작동하던 것을 보존합니다.

공유 계정이 아니라 전용 계정을 쓰십시오. OpenVPN 개발자들은 nobody 을 일반적인 예로 쓰는 습관을 경고합니다. 호스트의 다른 서비스가 이미 그 계정으로 실행 중일 수 있고, 있다고 생각하는 격리는 그곳에 없기 때문입니다.

데이터 채널 오프로드나 다르게 링크되는 빌드처럼 로컬 작업 부하를 바꾸는 기능은 어떤 작업이 필요한지를 바꿀 수 있습니다. 무언가 깨졌을 때만이 아니라 패키지가 바뀔 때 지도를 다시 보십시오.

계획을 적어 두고 복구 접근을 유지하십시오

배포 기록에는 관리자, 시작 신원, 의도한 정상 상태 신원, 그리고 각 부여와 그것을 요구하는 작업을 적어야 합니다. 그 기록이 다음 변경을 실험이 아니라 검토 가능한 것으로 만듭니다.

편집하는 동안 콘솔 접근을 열어 두십시오. 시작에 실패하는 유닛은 원격에서 고치기 어렵습니다. 변경을 완료라고 하기 전에 재시작과 완전한 재부팅을 시험하십시오. 재시작을 견딘 유닛도 네트워크가 올라오기 전에 실패할 수 있습니다.

성공은 이해된 최소 권한 수명 주기이지, 우연히 root가 아닌 이름으로 돌고 있는 프로세스가 아닙니다.