Bug 101902 - Containers (#100344): message filtering/policy
Summary: Containers (#100344): message filtering/policy
Status: ASSIGNED
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-07-24 19:01 UTC by Simon McVittie
Modified: 2017-08-01 11:31 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-07-24 19:01:54 UTC
+++ This bug was initially created as a clone of Bug #100344 +++

Bug #101354 does not let container managers arrange for messages to be filtered. This is part of the wish-list for Bug #100344, because it would eventually let us get rid of flatpak-dbus-proxy.

Design sketch:

* New named parameter:

      Allow: a(usos)
          Array of tuples (flags: u, bus name: s, object path: o, interface: s)

          If this parameter is given, it sets the messages and operations
          that are allowed.

          An empty array allows sending method calls to the message
          bus, and receiving exactly one reply or error for each method call
          successfully sent (unless it was NO_REPLY). It also allows
          receiving method calls from connections that are not in a container,
          and sending exactly one reply or error for each method call
          received (unless it was NO_REPLY). It does not allow receiving
          broadcast signals. This is the most restrictive possible policy.

          [TODO: Does it allow receiving unicast signals from connections
          that are not in a container?]

          Each array entry is a /rule/ which allows additional operations
          according to its flags. If the bus name is the empty string,
          it matches all bus names (and hence all possible connections).
          If the interface is the empty string, it matches messages with
          any interface or no interface. If the object path is "/" and
          the OBJECT_PATH_IS_SUBTREE flag is present, it matches messages
          with any object path or no object path.

              SEE:
                  The connection may call GetNameOwner(), NameHasOwner(),
                  GetConnectionCredentials(), etc. to inspect connections
                  that are in the queue to own the given bus name.
                  The object path and interface are ignored when checking
                  for SEE access.
              CALL_METHODS:
                  The connection may send method call messages to
                  connections that are in the queue to own the given
                  bus name. Implies SEE.
              RECEIVE_BROADCASTS (or RECEIVE_SIGNALS?):
                  The connection may receive broadcasts (or all signals?)
                  from connections that are in the queue to own the given
                  bus name, if they match the given object path and
                  interface.
              TALK: alias for SEE | CALL_METHODS | RECEIVE_whatever
              BUS_NAME_IS_SUBTREE:
                  The bus name is matched in the same way as arg0namespace
                  in signal match rules, instead of as an exact match.
              OBJECT_PATH_IS_SUBTREE:
                  In addition to messages that match exactly, the object
                  path matches messages with an object path that has
                  additional components. For example, "/foo" matches messages
                  with object path "/foo" or "/foo/bar" but not "/foolish".
                  Note that this is not identical to arg0path in signal
                  match rules.
              SEND_UNIX_FDS, RECEIVE_UNIX_FDS:
                  The connection may send, receive messages that contain
                  Unix fds and match the given bus name, object path and
                  interface.
              OWN_BUS_NAME:
                  The connection may use RequestName and ReleaseName
                  to own the given bus name. Implies SEE and TALK.
                  The object path must be "/" and the interface must
                  be "".

          Not giving this parameter is equivalent to providing policies
          that allow the confined connection to send and receive every
          message, own every bus name, etc. This is the least restrictive
          possible policy.

* o.fd.Containers.GrantAccess(a(uos): rules)
      Rules are as above, but bus name is implicitly the caller's
      unique name

* o.fd.Containers.RevokeAccess(a(uos): rules)
      Rules are as for GrantAccess. If a rule was added more than
      once, each revocation removes one of the identical copies.
Comment 1 Simon McVittie 2017-07-24 20:06:32 UTC
We also need to either allow all confined apps to send broadcast signals, or have a flag that lets them.

We also need to either allow them to send unicast signals, or have a flag that lets them, or consider it to be part of CALL_METHODS (perhaps renamed to SEND_UNICAST in that case).
Comment 2 Philip Withnall 2017-08-01 11:31:27 UTC
(In reply to Simon McVittie from comment #0)
>           [TODO: Does it allow receiving unicast signals from connections
>           that are not in a container?]

Yes, that’s used by a few system service implementations, right?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.