search

darwin-network / slash

1 stars 1 forks source link

stunnel should run unprivileged #10

Closed slingamn closed 6 years ago

slingamn commented 6 years ago

Use the setuid and setgid config lines; make sure it can still read the right certificates and connect to the right UNIX domain socket, even after SIGHUP.

eklitzke commented 6 years ago

Are you really running stunnel as root?

slingamn commented 6 years ago

That's correct.

Really what should happen here is that stunnel upstream should add support for seccomp-bpf; that way, the daemon's zygote can read arbitrary certificates and connect to arbitrary UNIX domain sockets, but the processes that actually serve traffic can be restricted to read/write/poll/gettimeofday.

eklitzke commented 6 years ago

That's one way of looking at it. Another way of looking at is that Unix has had capabilities for non-superuser processes to read credential files since day 1.

https://linux.die.net/man/5/group

slingamn commented 6 years ago

The hard part is getting cooperation from Certbot (which should probably have sole control over /etc/letsencrypt).

Here's the totally ridiculous thing we do to make the certificates available to exim: https://github.com/darwin-network/slash/blob/000542cc675371d6c4600b8c432ed14d3db6e8ca/etc/cron.daily/install-exim-certificates

eklitzke commented 6 years ago

Check this out. I rescind my earlier comment about groups. The way this works on Apache, nginx, etc. is they start as root, read the certificates, and then call setuid() and setgid() to become unprivileged. stunnel supports two configuration options, setuid and setgid.

slingamn commented 6 years ago

Closing out the discussion, there are three viable solutions:

  1. Use global setuid and setgid stunnel config options; make copies of the LE certificates owned by that uid/gid pair (because otherwise stunnel won't be able to SIGHUP reload them after dropping privileges). This is the solution that was implemented.
  2. @eklitzke wrote a patch to stunnel that (when compiled to use processes instead of threads), keeps the master process running as root and does setuid/setgid only in the worker processes (comparable to the Debian nginx package)
  3. Individual threads can have their own seccomp profiles, so keep the whole process running as root, but sandbox the worker threads.