IIRC most of the specifications in Linux I have seen (outside of systemd there are the FreeDesktop.org ones, for example) seem to be made to be forwards-compatible, so they won’t fail if something that is added in a new version of the specification is read in a system that only understands an older version.
In those cases it seems the preferable choice is to just silently ignore the new option, I don’t know if systemd actually prints warning (it would make sense because the unit files are critical to the system inner working) but, assuming those warnings contain the unit file and the affected properties, I would guess a Google search would easily let the user figure out that it’s for a unit option added in a newer systemd version than the one the user’s system is running.
Based on the feedback I have received so far, I have updated some sections including packaging guidelines, added a specific example and so on. I have added a summary of the feedback and some open questions in the wiki.
There were some questions “for FESCo”, but I think it’d better to discuss this here. FESCo doesn’t neccessarilly know any more about the subject than other people…
Mechanism: Do we support adding the idea of using more of systemd security settings by default and recommending them in the packaging guidelines? What specific mechanism should we use to accomplish this a) per service settings as proposed b) default overrides with per service opt outs ex: default override can set ProtectClock=yes but services like Chronyd will specifically disable this (Fedora uses this mechanism to set a timeout via /usr/lib/systemd/system/service.d/10-timeout-abort.conf c) drop-ins in /usr/lib (as Fedora already uses in some cases)
I really like the idea of providing a drop-in for all services with a few settings that’d apply to a great majority of services, like proposed in F40 Change Proposal: Systemd Security Hardening (System-Wide) - #18 by siosm. The few services that need a different setting can apply an explicit opt-out. For example, chrony.service could have an override drop-in with ProtectClock=no.
Unfortunately systemd doesn’t know if a service is a “distro service” or something external or local, so I don’t think we can apply it to all services on the system without breaking stuff.
Scope: Is limiting the scope to default system services in this release the right approach? Do we also want to target other high profile services like Nginx and PostgreSQL that are not included by default?
The scope is huge already. I wouldn’t add any more to it.
Impact: How should we should consider the impact for RHEL 10 since it is expected to be based on Fedora 40?
That’s really up to RH folks, but it shouldn’t be a problem really. The uses in RH are narrower than in Fedora, so if we can come up with a policy that works for our users, the users of RHEL should be happy too.
For example, PrivateNetwork=yes can only be used for services that does not need network connectivity by default.
AFAIK if the service is using socket activation it is still possible to use PrivateNetwork=yes. As an example I have suggested this for node-exporter. So if a service supports that it would still be possible to harden it as long as it only responds to incoming requests and does not initiate requests on its own.
For httpd etc. this would not be feasible as it needs to be able to bind to arbitrary ports but for other this might be possible. sshd might be a tricky one – it is in theory possible but people may suddenly get locked out of their system if they have been using a port other than 22 and set up their firewall accordingly.
Much of the work I am doing here ends up working with upstream projects unless the service files are shipped in Fedora only or upstream has different concerns from downstream etc and I don’t think this sort of ostree specific change would be suitable for upstream. Might be better for ostree editions to ship a global override similar to the service timeouts that Fedora already has.
If global drop-in is configured to hide /sysroot, what about ostree-related services that require access to /sysroot? e.g., ostree-remount.service, ostree-finalize-staged.service, etc. Maybe an inverse config for such services?
Yep. FWIW on upstream projects I am working with, instead of dropping settings which break services, I am introducing them defaulting to no so it is clear that we are deliberating making that choice and also so that a global override with additional hardening settings can still potentially work. Services which need that path should be explicit about that. I haven’t gotten around to updating the specific ones you are citing but if anyone wants to join the effort, please feel free to take a look at
Realistically given where we are in the Fedora 40 cycle, some of them are going to be Rawhide only (eventually in Fedora 41) at this point.
BTW I’m wondering if you are interested to open a change proposal “for ostree editions to ship a global override similar to the service timeouts that Fedora already has”.