Nixos-provided systemd hardening options are prone to cause problems for downstream users

[pbsds]

EDIT: original title was RFC: Should we turn all systemd hardening options to lib.mkOptionDefault?

Downstream issues where the configured nixos systemd service hardening options prevent certain niche use-cases are plentiful (example). These hardening options tend to skew towards making the services barely useable, thanks to systemd-analyze. Instead of requiring end users to learn and use lib.mkForce, I believe we should ease adoption and wrap all systemd hardening options with lib.mkOptionDefault.

Thoughts?

[surfaceflinger]

Since we're talking about systemd hardening - what if we had an alternative systemd module, where all hardening was already set to most strict possible values? Basically make the hardening optout instead of optin just like eg. IAM works.

ofc all of this could be easily overridable like you explained above.

also, instead of doing this change treewide, just provide an alternative and gradually we would have more and more hardened services, I'm not sure if anyone has pulled this out yet

[pbsds]

Or one could use groups/building blocks of hardening options. Anything fs related could be merged in with // reccomendedFsHardeningFlags. With this paradigm, yours would be allTheFlags // { butNotThisOne = false; }.

The struggle is that it would be difficult add new flags to allTheFlags, since the nixosTests does not cover everything

[Kranzes]

maybe related: #259217

[eyJhb]

Using lib.mkOptionDefault wouldn't really make sense, since you would still be required to find the default values of all the options, and set them to that.

I think some version of what @pbsds purposes makes much more sense, and could be added to a services that wish to harden easily.
Then there could also be some standard profiles for systemd hardening that could be used in combination with this.
Ie. services.myservice.enableHardening could be used, combined with default profiles systemd.services.<name>,hardening.light = true;, or something.

My current issue is with services such as transmission, where a lot of options are set, and unsetting all these options, it's actually easier to fork nixpkgs/fork the module, remove it all, instead of finding all the default values for all the systemd settings.

I don't agree with what was done in : #259217 , as it doesn't provide the user with any information on why it was done, or what setting those options to false (in this case), would change/allow it to work with (without finding the issue/PR anyways).

[SuperSandro2000]

Anything fs related could be merged in with // reccomendedFsHardeningFlags. With this paradigm, yours would be allTheFlags // { butNotThisOne = false; }.

This would make adding anything new to allTheFlags a major undertaking and potentially breaking a lot of services. We do not have tests for everything and it is not possible to test all the functions. eg regressions like #179444 could be triggered by new hardening options.

Also we shouldn't merge attrs but instead leverage the module system.

Instead of requiring end users to learn and use lib.mkForce

lib.mkForce should be basic knowledge how to use the module system. If you get an error message with conflicting values, then this already written in the error message.

[eyJhb]

Is there any reason to close this? It's still a real issue people run into.

[pbsds]

The problem still exists, but support for the proposed solution has stalled and viable alternatives have yet to be found. I'll repurpose the thread as documentation of the issue