1

I understand that chroot allows to isolate Postfix, so if an attacker gives an access to one of a Postfix program, he cannot maliciously change something outside of the chrooted directory.

Seems that it's a common practice to run Postfix in a chroot jail. For example, Debian installs Postfix in a chroot by default.

I have a few questions about it:

  1. How an attacker can give an access to the file system when only 25 and 587 ports are available from outside? How is it possible via the SMTP protocol? Does it have vulnerabilities?
  2. Why Postfix is highly recommended to install in a chroot, but Dovecot that publishes POP3/IMAP ports and stores emails in the file system is not?
  3. Is it as safe to use ProtectSystem in a systemd unit for Postfix as a chroot jail?
Improve this question

3 Answers 3

Reset to default
2

How an attacker can give an access to the file system when only 25 and 587 ports are available from outside? How is it possible via the SMTP protocol? Does it have vulnerabilities?

A protocol usually doesn't, but certain implementations may. Specifically, the "Sendmail" SMTP suite1 (which used to be the major Unix SMTP implementation for a long time) had a few security holes, some of them very famous examples at that.

Postfix was deliberately created to become a secure alternative to Sendmail, and much of its design – the usage of chroots, the multi-process architecture with strong separation between tasks – came directly as a response to the security issues that Sendmail used to have. (Sendmail consisted of one process that did everything, and it used to handle SMTP while running as root!)

1 Not to be confused with the 'sendmail' program in your /usr/lib, which indeed used to be Sendmail back then, but the one on your system is still Postfix and merely follows the interface of the original Sendmail.

Why Postfix is highly recommended to install in a chroot, but Dovecot that publishes POP3/IMAP ports and stores emails in the file system is not?

Dovecot does use chroot. Its architecture (as well as Postfix's, really) allows it to be done in a more fine-grained manner, so that e.g. the highly-exposed "login" processes can do this automatically, so it becomes a little less important to do the same service-wide. But POP/IMAP also makes it somewhat more complex than SMTP, as it needs to access mailboxes stored in user home directories (which was the traditional layout), so a single chroot wouldn't work for that kind of setup.

Improve this answer
2
  • It's Dovecot's IMAP mail storage requires mail in user homes, not the IMAP in general. Cyrus IMAPd doesn't have such a requirement — on the contrary, it requires a separate partition(s) (volumes) for all the mail, and it's stored owned by cyrus:mail on disk. And, POP certainly simple to the point it's negligible; IMAP is complex, but it's complex from the client-server protocol standpoint, and it doesn't move data between servers, so SMTP is the one most complex in the general aspect.
    – Nikita Kipriyanov
    Commented Apr 19 at 5:50
  • @NikitaKipriyanov: Neither does Dovecot. I specifically mentioned "the traditional layout" that it defaults to using; I'm aware that both Dovecot and Cyrus can be set up to use opaque storage in /var or wherever else. (The direct predecessor of Cyrus, the Andrew Messaging System, also kept mail in user home directories, though it didn't do IMAP yet.)
    – u1686_grawity
    Commented Apr 19 at 5:51
0

In fact, it's recommended to run everything in a jail )) At least everything that is listening on Internet. On the other side, "a 100% secure system is 100% useless" )) Security is always a kind of trade-off. I would suppose that Postfix protocol (SMTP) is no more secure than POP or IMAP, it's just less of security-concerned companies expose POP/IMAP ports outside corporate network, whereas SMTP is exposed much more commonly. Well known exploit on exposed ports is "code injection" - submitting the payload with a piece of text that somehow may be interpreted by the listening program as executable code. How exactly such exploits are built and submitted, is way beyond this discussion )) My personal opinion, that another implementation of SMTP - sendmail - has a more security-aware code than postfix, may be religious ))

Improve this answer
2
  • I agree that vulnerabilities in such a case can only occur through code injection, but in this case, if an MTA is just a relay and it hands off emails to MDA to store it in the file system (seems it happens in most cases), it means that MDA is also a weak link, but I've never seen in any book or post that an MDA also should be placed in a jail. Is there such a practice? I'm not sure it's possible if an MDA should communicate with MTA using different unix sockets (lmtp, sasl, quota status, etc), but if the MTA is on another machine in a private network, it sounds not bad.
    – Ilya Ordin
    Commented Apr 18 at 6:18
  • In principle misbehaving MTA may do much more harm than misbehaving MDA. That said, there is no point putting apps in jails when you can just put them into containers.
    – Nikita Kipriyanov
    Commented Apr 18 at 11:06
0

  1. Via yet unknown vulnerabilities. It shouldn't be possible to, but shit happens, sneaky backdoor libraries get included into even most important tools, people make programming mistakes, and so on. Postfix is often praised for its very clean code style, but it uses other software libraries which aren't as good.

  2. Techically you can't install it fully chroot. Postfix consists of many interdependent services, some of which do benefit from chrooting, some others cannot run in a chroot. For example, a proxymap service is designed specifically to give other, chrooted services a controlled access to items outside of chroot, and therefore it must not be itself chrooted. Whether the Postfix service runs in a chroot or not is set via corresponding flag in a master.cf file (the one in 5th column). Probably, Dovecot authors think it doesn't need such a protection.

  3. Postfix runs under the supervision of its own master process, configured using master.cf. It is not designed to run any other way, including systemd's ProtectSystem jail. The primary developer support of Postfix is provided via its "users" mailing list; they will not support you if you run it in such a jail.

Improve this answer
2
  • Does a program should be designed to run using a systemd jail? I mean theoretically, we can set in ReadWriteDirectories all the stuff needed to Postfix. Although it uses a lot of different directories, so i might be problematic, but what's the difference between systemd jail and chroot jail? Hope it's not an off topic. Sorry, I can't cast a vote, but thanks for your answer.
    – Ilya Ordin
    Commented Apr 18 at 6:28
  • First of all, say some programs are not designed to run in any kind of a jail. Like, what's the point of running, say, grub in a jail? Although Postfix is not a system software, it needs many outside accesses. Usually it makes accesses to traditional files like /etc/aliases, it may be configured to interact with other servers via Unix sockets living in arbitrary paths (think LMTP, antispam, whatever), or call arbitrary programs which themselves may be not supposed to be jailed. It has its own supervisor, which knows what to put into jail and what not, something that systemd can't know about.
    – Nikita Kipriyanov
    Commented Apr 18 at 7:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .