Bug 103458 - Containers (#100344): Work out what to do about unrestricted connections
Summary: Containers (#100344): Work out what to do about unrestricted connections
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: All All
: medium enhancement
Assignee: Simon McVittie
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 101354
Blocks: 100344
  Show dependency treegraph
 
Reported: 2017-10-25 18:23 UTC by Simon McVittie
Modified: 2018-10-12 21:32 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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:
  DBus.UpdateActivationEnvironment()
  (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
  server)
  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.