On a standard Debian box, SSL certificate and private key must be readable by Prosody to be used. However, the lua process is run by the user "prosody". Thus, the private key file must be readable by the user prosody. In my opinion, a private key file should only be readable by the root user. Currently, in the unlikely event of a security issue in the server, the user can potentially read the private key file. Maybe the main process should run as root until every data is read, and then drop its privileges?

Hi, I understand your concerns completely, but we are limited in exactly what we can do about it. Firstly, we avoid having any Prosody code running as root - and I'm reluctant to change that. It brings in the potential for a whole load of more obscure security issues that can be harder to identify than this is. Secondly, we may need to re-read the certificates at any time, not just at startup - so we would need to keep the root process around, or have a setuid binary. Again, more potential security issues. Finally, OpenSSL keeps the key in memory anyway. If there's a security flaw that allows reading from the key file there may also be a security flaw that allows reading from memory. This has been done in the past in other applications, there's little that can be done about it except making sure those security flaws don't exist in the first place - that's what we focus on. Hope this helps. I'm going to close this issue, but feel free to reply if you have any questions or comments about anything.

• tags Status-WontFix
• owner MattJ

Hi, I was actually expecting a discussion like that instead of a real solution right now. This is clearly not an easy issue to fix. However, the main issue for me is to let another system user than 'root' have an access to a private key, because it is also used to sign other certificates. Since I run my own CA, I can fix that by using another certificate using a different private key. And I definitely understand your reluctance to run a piece of code as root, even if it's the tiniest part. I was just suggesting that because a lot of services such as Apache, NGinx, PHP-FPM, unicorn, dovecot or postfix that act like that.

(continuing here from https://issues.prosody.im/1581) I too am used to most daemons reading their keys or doing other rooty things and then dropping privs. Prosody has prosody_user and prosody_group to do the same thing -- they are handled currently in https://hg.prosody.im/0.11/file/bacca65ce107/util/startup.lua#l446. But that is designed to be called by prosodyctl before it exec's into prosody, and that separation means there's no easy way to pass secrets acquired while root into prosody. This makes prosody stick out on my systems. I'm using https://man.openbsd.org/acme-client which makes files with permissions like this: comms3# ls -l /etc/ssl/{,private}/redcurrant.blue* -r--r--r-- 1 root wheel 3973 Aug 24 07:34 /etc/ssl//redcurrant.blue.fullchain.pem -r-------- 1 root wheel 3272 Aug 24 05:01 /etc/ssl/private/redcurrant.blue.key Zash told me > The general recommendation is to copy certificate and key files into /etc/prosody/certs and make them readable by the 'prosody' user. so my current workaround is to have this in my crontab: 0 * * * * sleep $((RANDOM \% 2048)) && acme-client redcurrant.blue && prosodyctl --root cert import /etc/ssl/redcurrant.blue.fullchain.pem && rcctl reload httpd relayd prosody OpenBSD is being being opinionated about how to lay out permissions, but like Adrien I think this is a reasonable precaution. In response to > If there's a security flaw that allows reading from the key file there may also be a security flaw that allows reading from memory. [..] [we focus on] making sure those security flaws don't exist in the first place I think the concern prosody isn't the only way to the _prosody user. If prosody itself gets hacked you'll lose your keys, but if a different daemon or user gets hacked you don't want to worry that they might grab your SSL keys too. It's a least-privilege thing. The workaround is alright for me. Hopefully having it here will help someone else in the future. But it would be nice not to need it. I even found https://issues.prosody.im/893 which sounds a lot like it agrees: make the startup phase (it's no matter whether that's in prosodyctl or prosody) able to handle all the difficult rooty parts before `switchuser()` happens. So maybe prosodyctl could just do a blind `cert import` before `switchuser()` or something? Or mmap() the cert and keys before exec()'ing? I dunno. Maybe I'm worrying a scab for nothing. --- Despite being a fuddy duddy here, thanks for prosody! It's always such a breeze to configure. This is one of the few things that leaves me scratching my head when I'm using prosody. Everything else is super straight forward.