Bug 105658

Summary: Containers message filtering/policy (#101902): SEE access control
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, bugzilla, dbus, desrt, james
Version: git master   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 105656    
Bug Blocks: 101902, 105659, 105660    

Description Simon McVittie 2018-03-21 12:45:16 UTC
+++ This bug was initially created as a clone of Bug #101902 +++

Implement the SEE access-control model as a step towards Bug #101902.

* Allow list can contain tuples with SEE flag and bus name
* If a contained peer calls ListActivatableNames, ListNames,
  NameHasOwner or GetNameOwner, names that it can SEE are not
  treated as if they didn't exist
* A contained peer can see NameOwnerChanged signals where the
  name in question is one that it can SEE
* If a contained peer can SEE a well-known name, then it can SEE the unique
  name that owns that well-known name too (the primary owner)
* If a contained peer receives a method call or unicast signal from
  outside the container, then it receives SEE access to the sender's unique name
* Add a named parameter or a special allow rule that lets the contained peer SEE every unique name
* Bus name can be "" to match anything
* Bus name can be combined with BUS_NAME_IS_SUBTREE flag to match like arg0namespace
* Object path is ignored for SEE checks
* Interface is ignored for SEE checks

To be designed
==============

One of these:

    * If a contained peer can SEE a well-known name, then it can SEE every
      unique name in the queue for that well-known name
    * If a contained peer can SEE a well-known name, this does not affect
      whether it can SEE unique names that are in the queue for the
      well-known name but are not the primary owner
Comment 1 Simon McVittie 2018-06-01 19:00:01 UTC
(In reply to Simon McVittie from comment #0)
> * If a contained peer receives a method call or unicast signal from
>   outside the container, then it receives SEE access to the sender's unique
> name

I'm implementing this part first.
Comment 2 Simon McVittie 2018-08-29 19:24:43 UTC
On Bug #105656 there is missing coverage for a contained connection inspecting an uncontained connection ("inspecting" means GetConnectionCredentials etc.). I can't actually test that until this feature is implemented: the caller needs to be allowed to SEE the other connection, but not inspect it.
Comment 3 GitLab Migration User 2018-10-12 21:34:19 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/203.

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.