0

Multiple daemon applications would like to access the same TLS certificates (or chain, or private) keys.

  • NGINX wants to access /etc/letsencrypt/live/example.org/privkey.pem
  • So does Apache.
  • And BIND.
  • And my favorite [sftdyn] Github package.

And they all run their daemon with different GID and group name.

My attempts at securing the private key in a safe manner, yet sharing it across different daemons (having their own GID) with the following various approaches (and some later nixed) are:

  1. Set file permission to "blaze of glory" chmod a+rwx. This got nixed because it reveals the secret privkey.pem file to the entire filesystem.

  2. Create a new group keys and add nginx, apache, named (or bind), and sftdyn group to the keys group in /etc/group (or using adduser nginx keys). Use new keys group on the PEM files. Then cap PEM files' permission with chmod 0640.

  3. Use setfacl.

Which of 2 or 3 is best to address this thorny issue?

John Greene
  • 2,239
  • 3
  • 26
  • 37

1 Answers1

1

System admin side of me believes strongly in "keep it simple" and says to do it via the "keys" group (or ssldaemons or whatever you want to name it - I think group names should describe the membership or purpose if possible) and regular old boring file system permissions.

On the other hand, if you are already using ACLs then using just another ACL rule or three would fit better into your work flow/policy/admin style.

If you aren't using ACLs already, then I wouldn't head down that road - no need to make things excessively complex. Unless of course you need an excuse to management to do it :)

ivanivan
  • 2,155
  • 2
  • 10
  • 11
  • Secondary group ID would be okay then? – John Greene Sep 10 '18 at 12:20
  • 1
    @EgbertS works fine, I use it to control a few other things so in my use case it had to be 2nd-ary groups. And, from a sysadmin side, adding a user's primary group to some user as a secondary group is against the design of the permissions model - it works, but it also removes the ability ot have a file/directory that is private to the first user. – ivanivan Sep 10 '18 at 20:22
  • Unless the file has root:secondgroup and 0750/0640? – John Greene Sep 11 '18 at 00:41
  • @EgbertS root isn't the only user that may need to keep things private. Think about hte private half of a public/private key pair? – ivanivan Sep 11 '18 at 00:57
  • Hence the `chown root:key ` notation? – John Greene Sep 12 '18 at 20:00
  • So the only downside to #2 approach is unintended leakage of other group’s other information toward the keys group. – John Greene Oct 08 '18 at 11:47