18.12.2024 01:12, Wietse Venema via Postfix-users wrote:
Just for the record, Postfix requires that a system behaves as defined in POSIX (and ANSI C). That remains the baseline for what calls are expected to succeed, and for what calls are expected to fail.
This is one of the possible views on this, - treating additional security measures as "breaking POSIX". Usually though, people think about this as additional layers to work with/within. Effectively, unix file permissions model already is breaking regular unix file operations on a single-user system, by adding one more possible reasons for file access to fail - this is EACCESS. A more interesting analogy is chroot(2): while it is in POSIX itself, but it makes quite a few other features defined by the same POSIX, effectively useless unless additional steps are performed: eg, getpwnam() does not work anymore (it always fails) unless you either use proxy: map type or copy /etc/passwd into the chroot jail. Linux capabilities are an additional security layer, which works together with POSIX, on top of POSIX, just like unix rwx permissions model works together and on top of unix open() etc file access system calls. Basically, what linux capabilities does is to break unrestricted root access into smaller pieces and control each of them independently, in a way similar to how setuid() does to file access. There are several sets of capabilities (effective, ambient, bounding, inheritable, etc), and by default (if no extra steps are done), everything is allowed. One of the capabilities is cap_dac_override, which (among other things) gives root-like access to filesystem. Drop it from a root process, and it can't access to restricted files owned by another user anymore, bypassing regular rwx permission model. This is one of the examples postfix expects to have, to open various privileged maps, for master(8) to open sockets in restricted postfix subdirs and so on. If we're to discuss adding this layer to postfix, we should either permit cap_dac_override to postfix, or to teach postfix to work with it being unavailable. Just like we can teach postfix to work with chroot by providing proxy: map type, or by working around some chroot restrictions by copying some files into chroot. Obviously the most effective way is to let postfix work with capabilities at per-process or per-context level, because different processes at diff. times have different requirements. I don't see a big reason to apply this sort of security enhancements outside of postfix entirely, because it is not effective. But the main point I was trying to make is this: just like chroot(), there might be additional layers, and some of them might be worth the effort to add. The capability thing isn't difficult, and I think I'll do a PoC just to show what I mean. It needs a few changes to postfix source code, but should be rather located and easy to follow. Thanks, /mjt _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
