andi-:

This commit introduces a new
systemd.services.<service-name>.defaultHarddefaultHardening option
that allows specifiying a profile level that should be applied.

Roos: There is no policy yet but I'd love to define one as part of this work. One of the rules I'd stick to is that we only ever add new profiles instead of modifying the old ones. At least as long as there are users of the "old" one in Nixpkgs. Those changes (to "old" profiles) need changelog entries so downstream users can adjust their custom units.

The unitConfig attribute isn't used (yet). I've been thinking about making them "clever" by doing "the right thing" depending on other attributes in the unit but haven't gotten around to actually figure out how that looks like. The main issue here being that they can quickly become "unpredictable" if they do too much.

Another avenue that I was looking at yesterday was selecting a list of profiles for each unit. Something like [ base-v1 network-service-v1 ] where the first one applies some generic hardening (DynamicUser, PrivateTmp, DevicePolicy, rough capability enforcement) and the 2nd one defines policies related to the network service. One example would be allowing AF_INET{,6} and/or AF_UNIX (which arguable every? service could have).

The main problem in composing those is that generally we can only get more restrictive as removing an element from the list of restrictions isn't currently possible. We also have to somehow merge multiple mkDefault statements if we go that route. Currently that should throw an eval error (conflicting statements).

Thus I think selecting from multiple profiles isn't great. At least not a first. We might as well "embed" the base-v1 definitions into the network-service-v1 definition.

As one of the last exercises I tried to run the Nginx service with the v1 profile from the linked commit but couldn't figure out which of the restrictions was responsible for the startup failure... We need proper tooling around this as otherwise it will become rather hard for the uninvolved hacker to adopt this in their units. If they can't debug this the entire exercise isn't worth it.

I'd stick to is that we only ever add new profiles instead of modifying the old ones. At least as long as there are users of the "old" one in Nixpkgs.

+1

I've been thinking about making them "clever" by doing "the right thing" depending on other attributes in the unit but haven't gotten around to actually figure out how that looks like.

I'd stick to simplicity and provide a fixed set of restrictions which can be overriden by the service config itself (e.g. A user can always services.foo = {defaultHardening = "v1"; ProtectHostname = false; }

re

I've been thinking about making them "clever" by doing "the right thing" depending on other attributes in the unit but haven't gotten around to actually figure out how that looks like.

my personal preference would be to lean on the restrictive side and have explicit toggles for permitting broad categories of thing