| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 107:38:10 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,678 |
What do you think about this aspect of postfix on debian?
The problem though, arises in 2 places.
1. Extra nsswitch modules, such as mdns, systemd-resolved (which is
optional since resolv.conf works), and so on, which expects their
files to be in the chroot jail (exacly like on FreeBSD with this
same mechanism).
2. Cyrus SASL, - for any non-trivial (PLAIN or LOGIN) methods, it
needs the secrets database to be accessible in the chroot, and
people on the 'net suggest really crazy things to fix this (like
moving /etc/sasl2 userdb to /var/spool/postfix/etc/ and symlinking
it back to /etc/sasl2).
3. Various postfix map lookup types which require additional stuff -
for these, there's an easy solution in postfix exists for over
20 years, which is a proxy: map. So this is not an issue.
My initial intention was to turn chroot in postfix immediately.
However, I can't do anything without understanding the root issues
first. And my discovery turned out to be quite interesting. So I
really wonder...
What do you think about this aspect of postfix on debian?
a) single power-user system (notebook/desktop) which has a local MTA
to send their own mail out to a proper mail server somewhere on the
internet
b) running a proper mail server on the internet
I do both and would welcome non-chrooted by default for both scenarios
in order to have a nicer, simpler and better integrated experience with
the rest of the system with less special casing. postfix would e.g. way
more profit from with namespace, capability and process restrictions set
(via systemd units?).
For a) not really much of a problem because one sends his/her own stuff
out without accepting mail from the outside, so relatively small chance
of malicious mails that could trigger some postfix bug to compromise the system.
For b), the real abuse/danger of the system isn't a malicious mail to
take out/over postfix, but the bazillion non-malicious-yet-unwanted
mails aka spam.
However, privilege escalation is still a serious issue and should not be minimized by its likelihood.
The "REAL" danger is the system takeover, as it is much more damaging to surrounding systems, harder to detect, and harder to recover from.
Using chroot is sometimes used as an excuse to leave things UNsafe, for obvious reasons. Better to fix the underlying issues and have a less complex system. Less complexity means easier to support, troubleshoot, AND keep secure.
But let us not minimize the importance of keeping our systems "un-pwned" by botnet operators. It's not about YOU. It's not about YOUR data. It's about not allowing your resources to become tools for malicious actors to use against everyone else.
What do you think about this aspect of postfix on debian?I do not remember ever having any issues about this, and I have been
So, I wouldn't object to undoing that given upstream's stance, but maybeYes, that's a very good suggestion. I'll definitely take a look at this list. It'd be nice to have some helping hand there, too.
it would be good to do that in conjunction with adding more hardening to
the default configuration with systemd? systemd-analyze security
postfix@- shows a whole lot of things that could potentially be improved
in hardening settings, and while a lot of those won't work becuase of the number of things Postfix needs to be able to do, a lot of them are
probably reasonable changes to the defaults if accompanied by instructions for how to turn them off with an override file. There is some obvious
stuff like ProtectSystem, PrivateDevices, or ProtectKernelTunables that
seems quite unlikely to break anything.
On Dec 16, Michael Tokarev <mjt@tls.msk.ru> wrote:
What do you think about this aspect of postfix on debian?I do not remember ever having any issues about this, and I have been
using Postfix since before it was called Postfix. But if Wietse says
that a chroot default is not worth it then I fully trust him.
The security track record of Postfix is good enough that I believe that chrooting is overkill./mjt
It turns out the reason for this is a myth, which we believed to for
25 years - a myth that "On FreeBSD, chroot is painless, but on Linux,
chroot never works and is only suitable for the ones who want pain". Actually, it looks like, chroot on linux is *exactly* the same as on
FreeBSD, and the pain level completely depends on which features you
use (I mentioned all 3 possible issues in my initial email). It feels
like this is the sole source of this opinion.
16.12.2024 20:08, Russ Allbery wrote:
So, I wouldn't object to undoing that given upstream's stance, but maybeYes, that's a very good suggestion. I'll definitely take a look at this list.
it would be good to do that in conjunction with adding more hardening to
the default configuration with systemd? systemd-analyze security
postfix@- shows a whole lot of things that could potentially be improved
in hardening settings, and while a lot of those won't work becuase of the
number of things Postfix needs to be able to do, a lot of them are
probably reasonable changes to the defaults if accompanied by instructions >> for how to turn them off with an override file. There is some obvious
stuff like ProtectSystem, PrivateDevices, or ProtectKernelTunables that
seems quite unlikely to break anything.
It'd be nice to have some helping hand there, too.
Anyway, systemd's hardening features are so easy and effective that I
would really like to see not only postfix, but ALL services use them as
much as possible. Why we still have major packages like nginx shipping without any hardening out-of-the-box?
I would also like to see this. Perhaps it's because the maintainers
don't want to close the door to alternative init systems, by making
their package depend on systemd features?
Adding a couple of lines to the systemd unit should not add any new dependincies to the package, or affect users of other init systems in
any way.
I would also like to see this. Perhaps it's because the maintainers
don't want to close the door to alternative init systems, by making
their package depend on systemd features?
Most likely it is because BSD does not have systemd, and quite a lot of Postfix installations, especially larger ones, run on BSD.
[...]
I don't see this happening without upstream support. However, upstream
has little incentive to do so: they currently have an orchestrator that works, is completely controlled by them and not subject to another
project's interface changes (rare as they may be), and is free to make
the assumption that the services being started are vaguely related to
mail delivery.
If they were to ship unit files, they'd end up in the same documentation nightmare as we would if we were to start doing so, and if they create a generator and start using systemd as the controlling process, they would
not gain anything, because neither can they drop their own orchestrator
(so this creates additional testing surface, as their services would now
need to implement *two* service manager protocols), nor would that
directly provide any additional functionality.
Hi!
For 25 years, Postfix the MTA in Debian has been setup to run chrooted by default (that's where most postfix internal components run chrooted in /var/spool/postfix/, to limit possible system damage after a possible compromise).
This setup has been criticized for 25 years, because of significant pain
it caused to users and upstream and postfix-users support. The conclusion
by Wietse Venema, who is the author of Postfix:
On Wed Dec 18, 2024 at 10:58 AM GMT, Henrik Ahlgren wrote:
Adding a couple of lines to the systemd unit should not add any new
dependincies to the package, or affect users of other init systems in
any way.
That's a very good point. In which case that's likely not why there is a
lag in adopting these things.
Perhaps we could have a release goal to set a certain bar in terms of hardening features for trixie+1?
BTW, is there a way for a systemd unit to take/inherit (security) settings from
another unit?
On Mon, 2024-12-16 at 21:21 +0300, Michael Tokarev wrote:
It turns out the reason for this is a myth, which we believed to for
25 years - a myth that "On FreeBSD, chroot is painless, but on Linux,
chroot never works and is only suitable for the ones who want pain".
Actually, it looks like, chroot on linux is *exactly* the same as on
FreeBSD, and the pain level completely depends on which features you
use (I mentioned all 3 possible issues in my initial email). It feels
like this is the sole source of this opinion.
I have never heard about such myth. Perhaps you are referring to the
FreeBSD jail feature, which obviously is superiour to plain chroot.
chroot(2) is a very simple and ancient Unix mechanism from 1979 and I
believe it is exactly the same on all Unix/Posix-style systems.
Anyway, systemd's hardening features are so easy and effective that I
would really like to see not only postfix, but ALL services use them as
much as possible. Why we still have major packages like nginx shipping without any hardening out-of-the-box?
Anyway, systemd's hardening features are so easy and effective that II would advise against this simplistic view on security and "hardening" -
would really like to see not only postfix, but ALL services use them as
much as possible. Why we still have major packages like nginx shipping without any hardening out-of-the-box?
Postfix's "master" process effectively implements an orchestrator for a microservice architecture, similar to what systemd does. This could beYes Simon, this is a very good summary, exactly to the point. Adding restrictions on top of postfix master(8) is ineffective, it should be
replaced by systemd by writing a generator that creates units from master.cf.
Simply converting the default master.cf to unit files and shipping these as default would still be a massive regression, because it would obsolete a
lot of documentation on how the Postfix system is orchestrated and how to integrate new services like clamav and spamassassin or to deliver to courier.
All of these recipes would become "instead of this one line in master.cf, you need to create a service unit, socket unit and possibly timer unit." My
expectation would be that the next sentence would be "Please refer to the systemd documentation on how to do that.", and while the systemd
documentation is exhaustive, it is significantly less targeted to the operation of mail systems than the manual page for the master.cf configuration
file format.
I would advise against this simplistic view on security and "hardening" -
it often makes false sense of security instead of real security.
Besides, I yet to see an actual explanation how current postfix chroot
is not as good as systemd unit hardening can bring us (omitting the complexity of postfix internal services architecture for now, let's
say, just for smtpd service alone). Which treats linux abilities
above POSIX (which can be applied using systemd or in other ways)
are handled "better" than postfix already handles with its internal hardening, including its own chroot?
Take bind9 named(8) for example – it can chroot (with -t) but AFAIKBecause it makes managing it much harder, since /etc/bind/ then moves to /var/.
Debian does not use it by default, and I think using the various
systemd sandboxing would be much more friendly approach. (The securityThis is a urban legend: actually you are thinking of BIND 8.
track record of BIND is sadly not the greatest.)
Postfix's "master" process effectively implements an orchestrator for a microservice architecture, similar to what systemd does. This could be replaced by systemd by writing a generator that creates units from
master.cf.
Simply converting the default master.cf to unit files and shipping these as default would still be a massive regression, because it would obsolete a lot of documentation on how the Postfix system is orchestrated and how to integrate new services like clamav and spamassassin or to deliver to
courier.
If they were to ship unit files, they'd end up in the same documentation nightmare as we would if we were to start doing so, and if they create a generator and start using systemd as the controlling process, they would not gain anything, because neither can they drop their own orchestrator (so this creates additional testing surface, as their services would now need to implement *two* service manager protocols), nor would that directly provide any additional functionality.
Hi Michael and Simon,
On Wed, Dec 18, 2024 at 10:16:12PM +0900, Simon Richter wrote:..
If they were to ship unit files, they'd end up in the same documentation
I'm not sure the generator approach needs to be ruled out that quickly.
The fields of master.cf map quite nicely to systemd. I'd interpret
Going back to the initial question of chrooting, I guess the main work
is done as chroot is what installations do by default. In the event that chroot poses a problem (which seems to be rare), individual processes
may be opted out of chrooting in master.cf at ease. Users who strongly
care about security would likely separate their installation into
multiple Postfix instances one of which is facing to the internet and
another to perform delivery to local users (likely running on different machines). The status quo does not look bad enough to me to warrant
serious investment here, but maybe I am not enough of a power user of
Postfix to understand the pain caused by chroots.
And there's no way to fix [an in-process plugin architecture] in current infrastructure, besides switching to dovecot auth (which works by implementing
a higher-level protocol than saslauthd does).