Skip to content

GitLab

Open
Created by Bugzilla Migration User@bugzilla-migration

Containers (#100344): message filtering/policy

Submitted by Simon McVittie

Assigned to Simon McVittie

Link to original bug (#101902)

Description

+++ 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.

Version: git master

Depends on

Blocking