Hi, Thanks for your clear and descriptive answer Wietse! My search so far only revealed the privileged network port. The items you describe make perfect sense in a POSIX environment, but a lot less in a dockerized environment.
On Thu, Feb 25, 2021 at 4:53 PM Wietse Venema <wie...@porcupine.org> wrote: > Good luck with that. Postfix is a general-purpose MTA for POSIX > environments and requires privieleges for certain operations. > > - Opening a privileged network port This can be handled either by docker via published port or via CAP_NET_BIND_SERVICE. > - Changing privileges to those of a local recipient In a docker container there's no such thing as a local recipient. The container is a service and the host just hosts services. > - Revoking file system access (chroot) This is already handled by docker via its overlay file system. > - Revoking configuration file write privileges This is easy to do by writing the configuration file prior to starting the service or mounting the configuration read only from outside the container. > - Revoking configuration file open privileges (for private keys) This one could be more difficult in a docker container, but then again, the idea of a docker container is to create small, self contained services. This service will either need the key or it won't. > You could do an experiment with an LD_PRELOADed shared object that > intercepts the problematic getuid() call, and that returns a result > that makes Postfix happy. Then you can see what breaks. > <cut very nasty hack to fool postfix into thinking it does run as root :) > To be honest, I'd rather run a supported service as root than hacking a service into thinking it runs as root in an unsupported way, but I admire your creativity. We are also investigating rootless docker, which runs the docker daemon as an unprivileged user. I'm not entirely sure what the impact will be on a process like postfix, but I assume it might be close to what your proposed hack does. User and group ids inside the container are mapped to other ids outside the container. > There are currently no plans for a so-called 'fixed-unprivileged > mode' because somoene would have to update every affected Postfix > feature and its documentation, and because this mode would need to > be supported for eternitity (updated and tested before every release). That's unfortunate. At the moment, postfix is the only container we use that cannot be run rootless. But if that's what it is, then so be it. It's not a huge thing for us, as I do trust the postfix master process to drop privileges the right way. And if someone were to escape from the process, they'll find themselves in a very confined, read-only filesystem with very limited possibilities. Best regards, Emond Papegaaij
