Rebasing, nothing changed.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/378

@GrahamcOfBorg test croc

@GrahamcOfBorg eval

I'm not sure about the aarch64-linux failure 🤷‍♂️

Rebased after cc8a422 added a conflicting line in nixos/tests/all-tests.nix.

@aanderse indeed it would make sense to upstream a few relevant settings (eg. SystemCallFilter=), but other settings:

• may be found too complex (eg. RootDirectory= needs InaccessiblePaths= and UMask= and RuntimeDirectory= and BindReadOnlyPaths= for paths specific to the Linux distribution);
• or opinionated because redundant (eg. DynamicUser=true currently implies ProtectSystem="strict"), to prevent a future unintended relaxing, either in NixOS to make a new feature work, or by systemd changing implied options;
• or would need to be removed from upstream or overridden (eg.: User=nobody or CapabilityBoundingSet=CAP_NET_BIND_SERVICE).

So, even though I can understand the immediate gain you mention in identifying and upstreaming relevant changes, my opinion so far is that:

• on a human level, it's too much cognitive load for me to adapt, explain, justify and beg a new upstream each time I try to better harden a service. An hardening which has generally already taken me several hours of boring bisects and tests of the settings. The more I'm willing to do is to mention those settings to upstream to let it take what it wants on its own;
• on a technical level, I find it is a pain to solve and maintain a coherent config with upstream's config in the mix, I find it more secure to not rely on upstream's knowledge and choices of security, but to have a single service config in NixOS, clearly using all the latest available hardening settings, and hopefully written by people who primarily care about security and are gaining experience by doing it on many other services.

I find it more secure to not rely on upstream's knowledge and choices of security

Alright, well as long as you know more about this software than developers of it do I completely support you 👍

I do find it unfortunate that other distributions won't be able to benefit from our (the NixOS community, a group of people generally keen on pushing the bar for security, as you mentioned) knowledge and efforts, though.

I find it more secure to not rely on upstream's knowledge and choices of security

Alright, well as long as you know more about this software than developers of it do I completely support you 👍

Of course I don't. But I would argue that even though developpers' intimate knowledge of their software may be useful to speed up elucidating all the permissions the software needs to have, and required in some cases, what matters most is knowledge of systemd/Linux and being concerned about security above other concerns. That is to say:

1. Be knowledgeable and used to configure systemd services and Linux's hardening options (capabilities, seccomp, sysctl, namespaces, apparmor, ...). Knowledges which are not necessary for the developpers to develop their software nor have a working-enough systemd service. Hence they may just not have it nor want to acquire/maintain it. As examplified here by upstream's User=nobody and CapabilityBoundingSet=CAP_NET_BIND_SERVICE.

2. Put security in a priority high enough to take the time to harden the service and have the will to make the usability and portability trade-offs required. For that matter I am personnally just not willing to go down a road hoping that each upstream (nor even each NixOS module's maintainers) holds security in such high priority. And I would prefer to have this concern handled by a dedicated security team acting transversaly accross all NixOS.

I do find it unfortunate that other distributions won't be able to benefit from our (the NixOS community, a group of people generally keen on pushing the bar for security, as you mentioned) knowledge and efforts, though.

I agree, and I'm not arguing against someone taking now time to argue with upstream to push some of those options, and this could be one of the secondary objectives of such NixOS security team. I'm just saying that concerning that software I'm exhausted and that:

The more I'm willing to do is to mention those settings to upstream to let it take what it wants on its own

You definitely have some good points. I have noticed some upstream developers are systemd friendly while others are not. Decisions should be made on a case by case basis, I guess.

@GrahamcOfBorg test croc

@ju1m I agree with you on deviating here. You have spent a reasonable amount of time to propose your changes to upstream.

To have users of other systems still benefit of your work, you might ask upstream to link back from their documentation to nixpkgs as an example for a more elaborate systemd setup.

I can merge this now, right?

I've notified upstream in schollz/croc#335 about this hardening.

Also, I've just seen that there are new hardening options ProtectProc= and ProcSubset= available on linux >=5.8, and it looks like they could be hardened too with ProtectProc=noaccess and ProcSubset=all but I first have to test them on a >=5.8 (currently linuxPackages = linuxPackages_5_4 in master).

@ju1m would you like me to merge this now or wait on that?

I've successfully tested croc with ProtectProc=noaccess and ProcSubset=pid (more restrictive than all) on linux 5.10 and systemd 247, both manually and by adding boot.kernelPackages = pkgs.linuxPackages_latest_hardened to nixos/tests/croc.nix's relay.
I've also:

• disabled @privileged syscalls.
• disabled access to /etc.

@aanderse thanks, for me it's good for merging.

@aanderse i think you can merge

Thanks team!