FS#73496 - [mumble-server] >= 1.4.230-1 needs integration with certbot
Attached to Project:
Community Packages
Opened by Christoph (cobzcs) - Tuesday, 25 January 2022, 10:33 GMT
Last edited by Toolybird (Toolybird) - Thursday, 23 February 2023, 22:28 GMT
Opened by Christoph (cobzcs) - Tuesday, 25 January 2022, 10:33 GMT
Last edited by Toolybird (Toolybird) - Thursday, 23 February 2023, 22:28 GMT
|
Details
Description:
Previously murmur was started with root privileges to read certificates and drops privileges afterwards (uname=murmur) option. Now (since 1.4.230-1) murmur is directly started as murmur user (murmur.service file). Certificates could not be loaded anymore. Additional info: There are three options in murmur.service which prevent the privilege drop: Group=murmur NoNewPrivileges=yes User=murmur Log: murmurd[1741]: <X>2022-01-25 10:36:39.768 SSL: OpenSSL version is 'OpenSSL 1.1.1m 14 Dec 2021' murmurd[1741]: <W>2022-01-25 10:36:39.768 Initializing settings from /etc/murmur.ini (basepath /etc) murmurd[1741]: <C>2022-01-25 10:36:39.768 MetaParams: Failed to read /etc/letsencrypt/live/******/cert.pem murmurd[1741]: <F>2022-01-25 10:36:39.768 MetaParams: Failed to load SSL settings. See previous errors. |
This task depends upon
Closed by Toolybird (Toolybird)
Thursday, 23 February 2023, 22:28 GMT
Reason for closing: No response
Additional comments about closing: Assuming fixed
Thursday, 23 February 2023, 22:28 GMT
Reason for closing: No response
Additional comments about closing: Assuming fixed
The title is not really correct, as now privileges do not have to be dropped anymore. The murmurd executable is not executed as root but as the murmur user now, whereas before it was run as root and then dropped privileges itself to the murmur user.
The implication of the previous behavior are, that murmurd has access to *all* certificates and *all files* (also by different groups) below /etc. This is now not the case anymore and from a security perspective the much more desirable outcome.
What is missing currently is to define where murmur is retrieving its certificates from (e.g. below /etc/murmur).
Please have a look at --deploy-hooks on how to do this: https://eff-certbot.readthedocs.io/en/stable/using.html?highlight=deploy-hook#renewing-certificates
I will keep this ticket open as grounds for discussion for a default location and a potential move of the configuration file (/etc/murmur.ini) to a namespaced location (e.g. /etc/murmur/murmur.ini).
In this context I came across this conversation:
https://community.letsencrypt.org/t/best-practice-for-exposing-private-key-to-locally-installed-programs/88158
Wrap-up:
Solution 1: Copy your certs into a folder which murmur has access to (best via deploy-hooks you mentioned before). For this, a namespace like /etc/murmur/ would be convenient, imho.
Solution 2: Use file ACLs (setfacl) to allow the murmur user to read the certificates explicitly. This only works if your FS supports ACLs.
For now I'm using ACLs.
I decided to go with cobzcs' solution of copying the certificates to another folder which the murmur user has access to.
In my deploy hook for certbot, I have the following:
/usr/bin/certbot renew --standalone --quiet --agree-tos --deploy-hook "/etc/murmur/copy_certs.sh && /usr/bin/killall -SIGUSR1 murmurd"
Where copy_certs.sh is a script I wrote to copy the certificates and set their respective permissions and ownership.
copy_certs.sh:
[ ! -d "/etc/murmur/certs" ] && mkdir --parents /etc/murmur/certs
cp --update /etc/letsencrypt/live/*******/*.pem /etc/murmur/certs
chown --recursive murmur:murmur /etc/murmur/certs
chmod -R 740 /etc/murmur/certs
This means, that /var/lib/mumble-server/ will become the most convenient location for placing certificate files.
Although /etc/mumble/ will exist, it is discouraged to places mumble-server's state there (and the directory is also world-readable).