22.12.2024 01:10, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
It looks like it's hardly possible to get away from cap_dac_override,
because it is relied on in a number of other places. Currently postfix
happily opens non-root-owned maps before chroot_uid() - and these maps
can reside in protected non-root-owned dirs. That will break with no
cap_dac_override obviously.
This is quite deliberate (a design feature), pipe aliases in non-root
owned aliases databases run with the priviliges of the alias file owner.
Sigh. What I pointed out above has nothing to do with pipe aliases
expanded by local(8).
Sorry, you mentioned that Postfix happily opens non-root maps,
ignoring that Postfix actually keeps track of ownership where it
can. Viktor's reference to user-owned local aliases is a response
to that point.
What I meant is like smtpd which opens relay_recipient_maps,
local_recipient_maps, virtual_alias_domains and whatnot before entering
chroot jail - before chroot_uid(). Local delivery agent does not use
chroot_uid() to begin with. This is the context.
...
Why are we still here? Because Debian's choice to chroot Postfix
is detrimental.
It is, and I admit this for 25 years in a row. I just don't want to
do the change drastically without deep thinking about consequences.
There are a LOT of guides on the net which assumes Postfix in Debian
is running chrooted, and by just switching chroot off, we'll make all
these guides wrong at once.
At the very least, this should be an install-time question, so the
user knows there was something about chroot. This is exactly why I
implemented this `postfix chroot' subcommand - to be able to easily
turn the damn thing on/off.
I do understand full well that this choice, together with 25 years
of consequences, is detrimental. I see my current task is 3-fold:
first, make the thing to be actually easier, by addressing numerous
omissions which were made before, to clean up the pre-historic
baggage we already have; second, to make it easy to turn on/off
(maybe just "off" on already installed systems); and third, to think
how to avoid breakage of the historic behavior. I'm at the 3rd point
currently, and the first 2 took large amount of resources and thinking
already, and it seems like I managed not to break everyone's Postfix
in the process, somehow.
Such things aren't done without thinking and actual understanding of
the problem at hand, and this is not an easy problem as it turns out,
with multiple compelling views and factors.
At the same time, while I discover actual reasons of various issues
in there, some part of me becomes a bit sad, because a LOT of issues
were actually for nothing and should've been solved differently (like
trying to make ldap: work within chroot which is a dead deal, instead
of using proxy:ldap:), and having in mind we survived these 25 years
with postfix being like this in debian, -- some part of me tells,
maybe it's already enough to just make the thing actually work as it
is supposed to work, plus give users an easy choice (postfix chroot off)?
Because if we just turn the thing off by default, no one will use it
and it'll bitrot, and it seems to be a nice feature despite all the
modern security enhancements elsewhere.
While digging into the thing, it *seemed* like the only *actual* issue
was the usage of external maps (ldap:) within chroot, because it is the
most common problem, reported in a lot of places. If it were the case,
it's easy to solve by using proxy: map type, and with that in place,
there seems to be no reason to change anything in Debain. Next I discovered
this SASL thing with auxprop plugins, which makes running within chroot
basically impossible (dovecot sasl works just fine and works equally
well with or without chroot).
Please don't get me wrong: I'm *for* turning chroot off exactly due to
it being detrimental for 25 years. But there are 2 interesting points.
First, it looks like what we had for 25 years is actually a myth coming
from one insufficiently well supported implementation in Debian. I'm
evaluating the *actual* reasons, hence my question about SASL and others.
And at the same time, what I see here is a possibility for better testing
and exposing which we're losing by turning it off by default. Testing of
a much better-working solution already.
This is what current README.Debian states (after completing steps
#1 and #2 above, without step #3! - the wording should be improved):
| The Postfix chroot feature is supposed to help only in cases where other
| aspects of system security are already addressed. In order to do this, one
| have to understand security by heart, just installing a Debian system with
| default settings is not enough. Due to this, running Postfix services
chrooted
| is usually overkill. It is strongly recommended that you turn off chroot
| feature in Postfix as shipped in Debian, if you can not solve a problem which
| is related to running Postfix chrooted. For this, run:
|
| # postfix chroot off
| # postfix reload
..
But this is a bit like dam has burst at a time that Postfx code is
made ready for the next stable Postrfix release early in the year.
Okay. Let's just assume the timing isn't good - it's unfortunate time
of the year when I come across the RFA (request of adoption) bug report
in Debian, and it's unfortunate I do have some resources to give to
this package ;)
...
There still is time to make that change in Debian before the next
stable Postfix release.
I'm not sure I understand, how Postfix stable release is related to
a change in Debian. Maybe you mean before the next stable *Debian*
release? If yes, sure, that's my plan exactly, it's just not a
thing which can be done without understanding and thinking first.
I'm working on this, it just need some more time.
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
