我知道 chroot 可以隔离 Postfix，所以如果攻击者获得某个 Postfix 程序的访问权限，他就无法恶意更改 chroot 目录之外的任何内容。
在 chroot jail 中运行 Postfix 似乎是一种常见的做法。例如，Debian 默认在 chroot 中安装 Postfix。
我对此有几个疑问：
- 当外部仅开放 25 和 587 端口时，攻击者如何能够访问文件系统？如何通过 SMTP 协议实现？它是否存在漏洞？
- 为什么强烈建议在 chroot 中安装 Postfix，但却不建议在 chroot 中安装发布 POP3/IMAP 端口并将电子邮件存储在文件系统中的 Dovecot？
ProtectSystem在 Postfix 的 systemd 单元中使用 chroot jail 是否一样安全？
答案1
当外部仅开放 25 和 587 端口时，攻击者如何能够访问文件系统？如何通过 SMTP 协议实现？它是否存在漏洞？
协议通常不会，但某些实现可能会。具体来说，“Sendmail”SMTP 套件1（曾经是这长期以来，Unix SMTP 的主要实现）一些安全漏洞，其中一些非常著名的例如。
Postfix 的设计初衷是成为Sendmail 的安全替代品，其大部分设计 — — chroots 的使用，即任务之间严格分离的多进程架构 — — 都直接针对 Sendmail 曾经存在的安全问题。（Sendmail 由一个可以完成所有工作的进程组成，它曾经在以 root 身份运行时处理 SMTP！）
1不要与 /usr/lib 中的“sendmail”程序相混淆，它当时确实是 Sendmail，但系统上的程序仍然是 Postfix，只是遵循界面原始 Sendmail。
为什么强烈建议在 chroot 中安装 Postfix，但却不建议在 chroot 中安装发布 POP3/IMAP 端口并将电子邮件存储在文件系统中的 Dovecot？
多夫科特做使用chroot。它的架构（实际上与 Postfix 的架构一样）允许以更细粒度的方式完成此操作，因此，例如，高度暴露的“登录”过程可以自动执行此操作，因此在整个服务范围内执行相同操作变得不那么重要。但是 POP/IMAP 也使其比 SMTP 更复杂，因为它需要访问存储在用户主目录中的邮箱（这是传统布局），因此单个 chroot 不适用于这种设置。
答案2
事实上，建议运行一切在监狱里 )) 至少互联网上监听的一切。另一方面，“100% 安全的系统 100% 没用” )) 安全始终是一种权衡。我认为 Postfix 协议 (SMTP) 并不比 POP 或 IMAP 更安全，只是更少的安全公司将 POP/IMAP 端口暴露在公司网络之外，而 SMTP 暴露得更普遍。暴露端口上众所周知的漏洞是“代码注入” - 提交有效载荷和一段文本，而监听程序可能会以某种方式将其解释为可执行代码。如何构建和提交此类漏洞，远远超出了本文的讨论范围 )) 我个人认为，SMTP 的另一种实现 - sendmail - 具有比 postfix 更安全的代码，可能是宗教性的 ))
答案3
通过尚不明确漏洞。这本来是不可能发生的，但糟糕的事情发生了，鬼鬼祟祟的后门库纳入即使是最重要的工具，人们也会犯编程错误，等等。Postfix 经常因其很干净代码风格，但它使用了其他软件库不太好。
从技术上讲，您无法完全 chroot 安装它。Postfix 包含许多相互依赖的服务，其中一些确实受益于 chroot，而另一些则无法在 chroot 中运行。例如，代理映射服务是专门为给予其他 chrooted 服务对 chroot 之外的项目的受控访问权限而设计的，因此它本身不能被 chrooted。Postfix 服务是否在 chroot 中运行是通过
master.cf文件（第 5 列中的文件）。可能 Dovecot 的作者认为它不需要这样的保护。Postfix 在其自己的进程的监督下运行
master，使用 进行配置master.cf。它不被设计为以任何其他方式运行，包括 systemd 的 ProtectSystem jail。Postfix 的主要开发人员支持通过其“用户”邮件列表提供；如果您在这样的 jail 中运行它，他们将不会为您提供支持。