Bug 103458

Summary: Containers (#100344): Work out what to do about unrestricted connections
Product: dbus Reporter: Simon McVittie <smcv>
Component: coreAssignee: Simon McVittie <smcv>
Status: RESOLVED MOVED QA Contact: D-Bus Maintainers <dbus>
Severity: enhancement    
Priority: medium CC: alexl, dbus, desrt, smcv
Version: git master   
Hardware: All   
OS: All   
i915 platform: i915 features:
Bug Depends on: 101354    
Bug Blocks: 100344    

Description Simon McVittie 2017-10-25 18:23:34 UTC
Flatpak has the concept of unrestricted connections to the session and system buses, selected by --socket=session-bus, --socket=system-bus. These bind-mount the session or system bus socket directly into the container if possible (or use flatpak-dbus-proxy in pass-through mode if the socket is abstract), without interposing flatpak-dbus-proxy --filter and its implicit restrictions on what the connection can do (such as forbidding UpdateActivationEnvironment()).

These connections are effectively totally trusted - there are lots of ways an unrestricted connection to the session bus can execute arbitrary code outside the sandbox context (doing the equivalent of `systemd-run --scope $your_payload_here` is an obvious one, and so is the o.fd.Flatpak.Development interface), and the same is probably true for the system bus. But we probably want to be able to *identify* these connections, even though we can't *control* them.

With the implementation in Bug #101354, there are some hard-coded things that such connections can never do:

* Call methods with METHOD_FLAG_PRIVILEGED:
  (privilege escalation via LD_PRELOAD etc.),
  DBus.BecomeMonitor() (privileged information leak)

* Call methods with METHOD_FLAG_NO_CONTAINERS:
  Containers1.AddServer() (privilege escalation via specifying weaker access
  control, identity spoofing by specifying a different identity for the
  Containers1.{StopInstance,StopListening}() (denial of service),
  the whole Verbose interface (indirect information leak, denial of service
  because Verbose is really really spammy),
  the whole Stats interface (minor information leak)

* Add match rules that enable eavesdropping (privileged information leak)

* Report that systemd activation has failed (denial of service)

* Probably more in future

I'm not sure whether a contained app will ever do these in practice. I could imagine GNOME Builder wanting to BecomeMonitor() or use Verbose or Stats, although at the moment it just uses --talk-name=org.freedesktop.Flatpak to escalate its privileges, rather than having a totally unrestricted socket.

Options include:

* Deny some or all of this on filtered connections (Bug #101902), let
  container managers allow it by adding extra allow rules, and maybe
  allow it on unfiltered connections (until Bug #101902, that's all
  connections) to preserve the invariant that not specifying filtering
  means allowing everything that can possibly be allowed

* Unconditionally forbid this stuff on the assumption that nobody will
  ever need it

* Either now, or later (if we unconditionally forbade it but we turned
  out to be wrong about never needing it), have a flag in the a{sv} of
  named arguments that relaxes our access control for a particular
  container instance (maybe {'AllowMonitoring': <true>} etc.?), and
  relax some of the restrictions in that situation

If we might let containers do privileged things in future, we might want to change the semantics of M_F_PRIVILEGED so that it's orthogonal to M_F_NO_CONTAINERS (in Bug #101354 as currently proposed, M_F_NO_CONTAINERS is strictly weaker than M_F_PRIVILEGED); or, alternatively, we might want to add a M_F_PRIVILEGED_UID that is really orthogonal to M_F_NO_CONTAINERS, which would make M_F_PRIVILEGED equivalent to M_F_PRIVILEGED_UID|M_F_NO_CONTAINERS.
Comment 1 GitLab Migration User 2018-10-12 21:32:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/189.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.