On Do, 03.03.22 10:04, Rahul Sundaram (metherid(a)gmail.com) 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