Make use of systemd's hardening?

[jvoisin]

I've been toying with systemd-analyze security, and the results for systemd-analyze security speakersafetyd.service aren't super-duper-great. While speakersafetyd is written in Rust, it's still running as root, which is scary. Would it make sense to make use of systemd's hardening to reduce a bit the attack surface? If so, I'd be happy to send a pull-request.

[chadmed]

I don't see why we wouldn't consider a PR that materially hardens speakersafetyd. However, I will frown upon any changes that assume the machine has systemd or that we are running on Fedora Asahi Remix. Don't pull in systemd, SELinux, etc. as hard dependencies. Beyond the fact that many non-systemd distros have mature Apple Silicon support and we would be pulling the rug from under them, we should be treating speakersafetyd as a model solution to userspace speaker protection. Embedded devices could make use of speakersafetyd with a little work, but not if they have to pull in systemd-heuristicservicehardeningplusdrmbluescreenofdeathd.

Keep in mind also that systemd-analyze security doesn't know what speakersafetyd does at runtime, and so assumes it is a "god mode" program that can do anything. speakersafetyd does not expose a way to exploit many of the "risks" it complains about. If you do decide to contribute a PR, carefully consider whether or not the changes materially improve security given the functionality speakersafetyd actually has access to at runtime.

[dkwo]

Perhaps related to this, would it be possible to run this service as a non-root user, perhaps in the audio group?
If this is not enough for it to work properly, are there any linux capabilities that would do the job?
Many init systems now support running the process with specified capabilities (e.g. systemd, dinit, even runit using setpriv).

[dkwo]

In my experient with Void Linux void-linux/void-packages#54446 I only had to patch it to use /run/speakersafetyd/speakersafetyd.flag, so that I can chown the dir before hand. Other than that, it seems to work fine being in audio group with no extra capabilities, at least audio works and it emits no errors/warnings. I will wait for feedback from upstream before merging it though.

[dkwo]

Just to follow up: running as non-root with no capabilities has been working fine for me. The user is in audio group, and the only change is as I said: vsed -i src/main.rs -e "s/speakersafetyd.flag/speakersafetyd\/speakersafetyd.flag/" to create a folder in /run, which I can chown before hand.

[dkwo]

Given that the process uses uclamp, maybe it is safer to give it CAP_SYS_NICE ?