I have a dropin called security.conf that I link in to most of my services, and then create an unsecurity.conf to disable/revert any directives not compatible with the service.
MemoryDenyWriteExecute gets set back to "no" quite a lot because interpreters like to use it for JITing, but it prevents a whole class of exploits on services where it can stay enabled.
I also like to socket-activate services as often as possible so they don't need access to network interfaces. Even if a service doesn't support socket-activation itself, it can usually be shimmed in with systemd-socket-proxyd, which also provides good functionality for stopping services when there are no connections to them (they get started again by the next connection).
> then create an unsecurity.conf to disable/revert any directives not compatible with the service
I've been using linux for something like 25 years now, and this just sounds like a heck of a lot of grokking and work (and maybe even trial and error?) for the mortals, no? I would think distribution maintainers should be the ones flipping more of these switches, and if they aren't, might that point to them being overly aggressive?
> this just sounds like a heck of a lot of grokking and work (and maybe even trial and error?) for the mortals, no?
Absolutely. For the record, when I say "my services" I mean services that I'm writing, not any service running on my system. I consider this hardening to be part of development, to be done by the developer responsible for it, whether that's the upstream dev or package maintainer. I would not consider it to be the responsibility of a random end-user and I wouldn't recommend most to try unless they're personally interested in it.
That being said, for developers, these switches make it crazy easy to sandbox your service compared to older solutions. So much so that I actually bother doing it now.
I know the post linked to systemd docs, but Iād enjoy seeing some snippets of directives people are using to achieve this kind of hardening.