On Sun, 22 Dec 2024 at 14:39:35 +0300, Michael Tokarev wrote:
> 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).
This is a recurring pattern: if
22.12.2024 10:24, Helmut Grohne wrote:
Hi Michael and Simon,
Hello Helmut! :)
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.
Hi Michael and Simon,
On Wed, Dec 18, 2024 at 10:16:12PM +0900, Simon Richter wrote:
> 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 fr
On Dec 19, Henrik Ahlgren wrote:
> Take bind9 named(8) for example – it can chroot (with -t) but AFAIK
> Debian does not use it by default, and I think using the various
Because it makes managing it much harder, since /etc/bind/ then moves to
/var/.
Systemd directives like ProtectSystem, ReadOnl
On Thu, 2024-12-19 at 11:04 +0300, Michael Tokarev wrote:
> I would advise against this simplistic view on security and "hardening" -
> it often makes false sense of security instead of real security.
Yes I agree, also blindly applied "hardening" settings can cause the
program not function correct
17.12.2024 00:31, Henrik Ahlgren wrote:
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 wo
18.12.2024 16:16, Simon Richter wrote:
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 mast
17.12.2024 00:31, Henrik Ahlgren wrote:
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 wa
"Jonathan Dowland" writes:
> 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 li
Michael Tokarev writes:
> BTW, is there a way for a systemd unit to take/inherit (security) settings
> from
> another unit?
You might want to look at the examples here
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/postfix%40.service.d
(from Trent W. Buck
Hola,
On Mon, Dec 16, 2024 at 05:51:34PM +0300, Michael Tokarev wrote:
> 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 possib
On 18/12/24 14:16, Simon Richter wrote:
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
On 16.12.24 15:51, Michael Tokarev wrote:
What do you think about this aspect of postfix on debian?
We now have systemd, which can sandbox far more aspects of postfix (or
indeed any other daemon)'s execution than is possible with a chroot,
esp. considering the hacks we need for that to actual
Hi,
On 12/18/24 19:38, Jonathan Dowland wrote:
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 lo
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
On Wed, 2024-12-18 at 10:38 +, Jonathan Dowland wrote:
> 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 n
On Mon Dec 16, 2024 at 9:31 PM GMT, Henrik Ahlgren wrote:
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-
16.12.2024 20:55, Michael Tokarev wrote:
16.12.2024 20:08, Russ Allbery wrote:
So, I wouldn't object to undoing that given upstream's stance, but maybe
it would be good to do that in conjunction with adding more hardening to
the default configuration with systemd? systemd-analyze security
postf
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,
16.12.2024 20:45, Marco d'Itri wrote:
On Dec 16, Michael Tokarev 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
16.12.2024 20:08, Russ Allbery wrote:
So, I wouldn't object to undoing that given upstream's stance, but maybe
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 coul
On Dec 16, Michael Tokarev 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.
On 12/16/24 17:45, rhys wrote:
> However, privilege escalation is still a serious issue and should not be
> minimized by its likelihood.
I didn't, my point is that I think they are better/more effectively
adressed with other mechanims (systemd unit hardening) than chroot.
> The "REAL" danger is t
Michael Tokarev writes:
> 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
Please read all the way to the bottom before replying. It will save time.
> 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 b
Hi,
first - thanks a lot for working on postfix packaging, it really needs
some love.
On 12/16/24 15:51, Michael Tokarev wrote:
> What do you think about this aspect of postfix on debian?
my opinion in short: I would get rid of the chrooted complexity, it's
not worth it and introduces way more p
26 matches
Mail list logo
