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.