On Do, 03.03.22 10:04, Rahul Sundaram (metherid@xxxxxxxxx) wrote: > > 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. > > > > What I would suggest here is we make it easier to adopt the opt out model > by explicitly setting services to opt out for things they can't handle, ie) > if a core set of services we ship within Fedora itself needs some > permissions including ProtectHome to false, push for upstream/distro to > have those knobs to be false explicitly within the service so the > permissions it needs are more clearly documented within the service itself > and then if a hardened variant of a distro or a sysadmin wants to flip the > model, they will have a considerably easier time with this. Nagging is a > good starting point but doesn't go far enough. The adoption of these > features is still very low. We can do better. I agree with the goal, but there's another problem: we keep adding new sandboxing options pretty regularly. If we'd turn them all on by default we'd keep breaking software over and over again as we add new knobs. For systemd's portable service concept, we came up with a scheme of "profiles", that group a number of sandboxing options under a name. A service then adds a .d/ dropin symlink pointing to one of these profiles, is then comprehensively locked down. The idea is that we'll add new profiles as we add new security knobs, and services always declare their intended profile, with the current, toughest being the default. That way older versions of packages would stick to weaker sandboxing, thus not breaking anything. There have been various requests of generalizing this, and making it available for any kind of service, not just portable services. I'd be onboard with that actually, but there are some unanswered questions regarding how distros and packages would start switching to a world of profiles, where suddenly things are locked down by default. But it would be a different model then: instead of individually turning on knobs, each software would pick a profile to use, and every year or so would be expected to update to a more current profile with stronger protections. If it doesn't do that it would continue to work, but it would be clear it is security-wise out of date. 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
