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