On Mon 2019-02-11 10:31:12 -0500, Scott Kitterman wrote: > The one trick I don't think that can be managed this way is that currently > dkimpy-milter reads the private key files as root and then drops privileges > so > that it doesn't have access to the key while running (it's only in memory). > Opendkim does similar, which is where I got the idea.
Ah, thanks for pointing this out. The simple approach is to ensure that the given user has *read-only* access to the keys in the filesystem while it's running. This isn't a significant expansion of privileges, since it already has this data. Downsides: you're now bound to leave access to this chunk of the filesystem while the daemon is running, which prohibits future lockdown enhancements like chrooted operation. (there is no current chrooted operation, so i think that's not a serious problem) This is a pretty common pattern, and it's used by (for example) the ssl-cert package, which makes /etc/ssl/private group-readable by group ssl-cert. Another advantage of this approach is that anyone exploring the filesystem permissions has a clear view of who might be getting access to this data. (by comparison, starting as root and dropping privs means that any bugs in or before the priv-dropping mean that the code has access to everything in the entire filesystem). If this approach is unsatisfactory for some reason, let me know. i'd be happy to brainstorm other ways to make sure that the secrets can be injected into the running non-privileged daemon. > I'm happy to add additional functionality to integrate better with systemd, > but with my upstream hat on, it needs to not be tied to systemd since it has > a > broader audience. right, understood. it's a bit of a shame to have a lot of system management code (dropping privileges, opening sockets, etc) in a daemon, but i can see how on a platform where the system manager doesn't do proper management, every daemon needs to fill in the gaps. I suppose if we can isolate the system management code and ensure it doesn't get run (or even loaded?) in a context where it knows it's properly managed, that might be the way to go. > I would appreciate help on this, to the extent it makes sense given > the need to work on non-systemd systems. Another option on those systems is to launch the daemon wth something like systemd-socket-activate in a chained command with runuser, like this: systemd-socket-activate -l /path/to/socket -- \ runuser -u dkimpy-milter -- \ dkimpy-milter /etc/dkimpy-milter.conf I know that people who don't have systemd might not have systemd-socket-activate available, (see https://bugs.debian.org/922082), but i've also written a comparably simple socket-activatable wrapper that i'd be happy to publish if it would help. --dkg
signature.asc
Description: PGP signature
