On Do, 03.03.22 09:25, Rahul Sundaram (metherid@xxxxxxxxx) wrote: > Hi > > On Thu, Mar 3, 2022 at 8:18 AM Zbigniew Jędrzejewski-Szmek wrote > > > > > What do you mean by "global service overrides"? > > Currently security hardening features are opt-in. You will have to set it > on a per service level. What I would prefer to see is the ability to have > an opt out of hardening features ie) the ability to set an override for all > systemd services such that it uses ProtectHome as an example and then > individual services can opt out. Yes, opt-out would be better than opt-in, but it would be a major compat break, UNIX software doesn't expect to be sandboxed, so if you sandbox everything out-of-the-box you'll be drowning in bugs, and the failure modes are not overly nice, i.e. you'll mostly rely on EPERM/EACCES hopefully being logged sanely by the relevant software. ProtectHome= for example implies that a separate mount namespace is allocated for each service. if you enable that for *all* services at once, then this means all services will suddenly live in their own mount namespaces, and the mount they establish will not propagate elsewhere anymore. Thus you broke at least udisks, storaged, homed, systemd-runtime-dir@.service and these kinds of things — because they exist precisely to establish mounts in the system. Adding security into a system that didn't have it but is widely deployed and developed for is *hard*. It makes opt-out security really hard to do, which is why we went for opt-in. Tools like "systemd-analyze security" exist primarily as a vehicle to pressure people to actually do the opt-in then, i.e. to "shame" them into looking into these knobs. (That said, there actually *is* a way to enable service settings for all services at once. But you can't really use it for what you are proposing on a general purpose distro I figure. i.e. if you drop in /etc/systemd/system/service.d/*.conf for example, the relevant settings will be imported into *all* services at once. YMMV.) Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
