요약

  • Postfix의 권한 있는 master는 대부분의 서비스 데몬이 초기화 과정에서 필요한 파일을 열 기회를 얻은 뒤 요청 처리 전에 root를 포기하게 합니다. 네 개의 전달 서비스는 제한된 작업을 위해 저장된 root 신원을 유지합니다.
  • 비권한 master 옵션은 감독 프로세스의 권한을 좁히지만 일부 내부 분리를 제거하고, 비밀 정보와 로그가 침해된 서비스에 더 많이 노출되며, 한정된 운영 구성에만 승인됩니다.

메일 시스템에서 첫 번째 보안 질문은 지나치게 단순하게 제기되곤 합니다. root로 실행하는가? Postfix의 아키텍처는 더 유용한 질문을 국지적으로 만듭니다. 어떤 프로세스가 요청의 어느 시점에 어떤 권한을, 그리고 어떤 파일이나 다른 사용자의 자원에 대해 필요로 하는가?

SMTP 또는 QMQP로 수신된 메시지는 먼저 네트워크에 노출되는 Postfix 서비스에 도달합니다. 이 서비스는 입력을 검사하고 봉투와 메시지를cleanup(8)에 전달합니다. cleanup은 큐잉 전 마지막 처리를 수행하고, 메시지를 수신 큐에 기록한 뒤qmgr(8)에 통지합니다. 큐 관리자가 다음 단계의 전달 에이전트를 선택합니다. 큐 관리자는 제한된 활성 큐만 유지하므로, 대량의 적체가 있더라도 큐에 쌓인 모든 메시지를 한꺼번에 열 필요가 없습니다. 상주하는master(8)프로세스는 이 서비스 집합을 감독하며, 요청 시 시작하고 구성된 프로세스 한도를 강제합니다.

이 구분이 중요한 이유는 감독 프로세스와 요청 처리 데몬이 서로 다른 역할을 하기 때문입니다. Postfix의 권한 있는 master 모델에서 서비스는 root 권한으로 시작해 TLS 개인 키나 데이터베이스 비밀번호 같은 민감한 파일을 열 수 있고, 그다음 요청을 처리하기 전에 되돌릴 수 없이 root를 포기합니다. 현재 보안 문서에 따르면 그 이후 침해된 서비스는 더 이상 해당 민감 파일, 데이터베이스 또는 로그 파일을 열 수 없습니다. 따라서 root는 수명 내내 모든 네트워크 지향 프로세스에 부여되는 일괄 권한이 아니라, 초기화와 권한 선택의 일부입니다.

이 모델에는 예외가 있습니다. 대부분의 서비스는 root를 영구히 포기하지만,local(8),pipe(8),spawn(8),virtual(8)은 저장된 유효 root 신원을 유지합니다. 대상 사용자로 전환하거나 메일함, 외부 명령 등 Postfix가 아닌 자원을 다루기 위해 이것이 필요합니다. Postfix는 이러한 용도를 구분합니다. root는 Postfix 서비스 간에 권한을 분리할 수 있고, 서비스가 사용자의 파일이나 Postfix가 아닌 프로그램으로 넘어갈 때 Postfix를 제한할 수 있습니다. "root 프로세스"라는 단일 라벨은 이 서로 다른 경계를 가립니다.

Wietse Venema는 2010년 LISA 발표에서 Postfix를 분할된 최소 권한 아키텍처로 설명했습니다. 그는 영향 중 하나를 메일 수신과 전달을 저권한 chroot 프로세스로 분리한 방화벽 설계로 추적했습니다. 발표는 또한 통신 인프라가 존재하는 상태에서 별도 프로그램이 유지보수에 도움이 될 수 있는 이유를 설명합니다. 이는 설계에 대한 역사적 서술이지, 현재 Postfix 데몬 수의 집계나 보안 결과의 측정이 아닙니다. 운영상 세부 사항은 현재 아키텍처 문서가 제공합니다. 메시지 수신, cleanup, 큐 관리, 전달은 서로 구분된 서비스로 남아 있습니다.

최근 변경은 감독 프로세스에서 root를 제거하면 자동으로 시스템 전체가 더 안전해진다는 주장이 아닙니다. Postfix 문서에 따르면 Venema는 2025년 미공개 통합 테스트를 위해 비권한master(8)동작을 처음 구현했습니다. 2026년 고객 문의 이후 그는 이를 제한적 운영 사용에 맞게 조정하고 문서를 추가했습니다. 이 모드에서 master는 root 대신 고정된postfix신원으로 실행됩니다. 그러면 서비스들은 초기화 중과 요청 처리 중에 동일한 Postfix 권한을 갖습니다. 문서는 이것이 Postfix의 내부 권한 분리, 그리고 Postfix가 아닌 파일 접근, 메일함 전달, 외부 명령 실행 시의 통상적인 제한을 유지할 수 없다고 명시합니다.

이 선택에는 실무적 결과가 따릅니다. Postfix 비밀 키 파일은postfix사용자가 읽을 수 있어야 하므로, 침해된 서비스가 읽을 수 있습니다. 선택적 Postfix 로그 파일은postfix소유여야 하므로, 침해된 서비스가 해당 기록을 읽거나 변경하거나 삭제할 수 있습니다. 구성은postfix사용자 소유 밖에 있어야 합니다. 다중 인스턴스 환경에서는 모든 인스턴스가 권한 있는 master를 쓰거나 모두 비권한 master를 써야 하며, 두 모드를 혼용할 수 없습니다.

운영 허용 범위는 좁습니다. 문서는 SMTP 또는 LMTP로 모든 메시지를 전달하는 배포에 한해 비권한 master를 허용합니다. 로컬 서비스가 Postfix가 아닌 프로그램을 실행하거나 메일함 파일로 전달할 수 있는 경우 운영 환경에서 이 모드를 사용하지 말라고 명시합니다. 한 가지 명시된 위험은 사용자의.forward파일에 넣은 명령이 해당 사용자의 권한 대신postfix권한으로 실행되어 사용자가 메일 시스템을 제어할 경로를 얻게 된다는 것입니다. 이 경고는 구성에 따라 달라지지만 명시적입니다.

아키텍처적 교훈은 "root가 안전하다"거나 "root가 불안전하다"는 것이 아닙니다. 권한의 이동이 경계 사이에서 위험을 옮긴다는 것입니다. root 없는 master는 제한된 릴레이 배포에서 매력적일 수 있지만, 서비스 프로세스들은 권한 있는 모델이 초기화 후 권한 포기 경계 뒤에 둘 수 있는 비밀 정보와 로그에 대해 접근을 공유하게 됩니다. 운영자는 master의 신원을 바꾸기 전에 전달 경로를 분류하고, 선택한 모드가 각 서비스가 도달할 수 있는 파일과 명령과 여전히 맞는지 확인해야 합니다. 공개 문서는 이 트레이드오프를 정의할 뿐, 운영자가 어느 모드를 얼마나 자주 선택하는지, 실제 배포에서 어떤 보안 결과가 뒤따르는지는 확립하지 않습니다.

출처