On 2024-12-19 08:39, Michael Tokarev via Postfix-users wrote: > > I don't see a reason to play with capabilities outside of postfix source > code: it is ineffective. If we're to adopt capabilities, we should teach > postfix itself to manipulate them on per-service or per-context basis.
I doubt you can do that. This is highly tight to system configuration - I for example expect only selected users to be able to maildrop (mimedefang), but there might be people depending on this feature for every system user. Not to mention this is Linux-specific and, to be honest, not well thought (and implemented like this). Since postfix in general: 1. manipulates user-owned files (mailboxes/maildirs), 2. have access to user-created files (.forward), 3. above files can reside in different locations, including $HOME, 4. delivers mail to all system accounts, including root, it's really not possible to strip out anything by default. You can disable /home access for virtual-only, without any ~/.forward and with e.g. LMTP-only delivery via dovecot (then it's the dovecot even harder to lock up). > Even there, with your ambient capabilities idea, someone has to enable > the necessary capabilities which are ambient and are needed in some > particular context - this has to be done within the postfix source. No, the ambient caps idea makes postfix less-rooty - and that's it. Capabilities granted are available for all the daemons before set_euid() and it could only be made more fine-grained if... > Postfix's master(8) is a service manager itself, who runs different > services with different privileges (okay, it's each service who > deals with its own privs at startup). The point is that each service > needs its own things, and attempting to apply something globally to > whole master process tree isn't going to work. ...exactly this. > We can drop some stuff (like cap_sys_reboot), but that's about it - > it is not very effective to do that. That's not the end of the story. After stripping capabilities there are prctl settings (no new privs - remember that those SGID binaries are not called from postfix.service), device policy, ProtectProc, ProcSubset, ProtectSystem, PrivateTmp, PrivateIPC, ProtectClock, ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs, MemoryDenyWriteExecute and so on. Also: ProtectSystem, ProtectHome or ReadOnlyPaths with ReadWritePaths exceptions - again, usable only as a part of runtime configuration. Then there's No/ExecPaths - if postfix.service=>master is expected to run only /usr/lib64/postfix/ binaries, then there's no point in having entire /usr/bin executable (and one can bind-mount what's missing). Having all of this you keep root with cap_dac_override restrained in mostly read-only environment, that even when compromised is _relatively_ safer. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
