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 correctly in use cases not tested by the DD doing the packagking, and possibly even weaken security. In any case, postfix is rather special having an internal complicated sandboxing and privilege separation architecture, which most services don't have. So my comment was perhaps more about adding them to many other services (especially Internet facing) that lack any such features. 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 systemd sandboxing would be much more friendly approach. (The security track record of BIND is sadly not the greatest.) Of course, we already do have plenty of packages with fairly strict systemd security settings, e.g. chrony or tor. I do believe those "hardenings" bring real security benefits, and they are much more easy to understand (or fine tune) than SELinux or AppArmor profiles – which chrony and tor also have, BTW, belt and suspenders I guess. > 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? At least I would be very careful with patching postfix code to drop any chroot based security it has from the actual source. Better work with the upstream author. But let's not forget, chroot only sandboxes the file system, the are other things that can be limited as well, like CapabilityBoundingSet.
