Bug 105661

Summary: Containers message filtering/policy (#101902): allow dconf etc. to grant extra accesses
Product: dbus Reporter: Simon McVittie <smcv>
Component: coreAssignee: D-Bus Maintainers <dbus>
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   
i915 platform: i915 features:
Bug Depends on: 101902    
Bug Blocks:    

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

Allison Lortie wants dconf to be able to give contained apps access to specific subtrees of the dconf object path tree, without giving them general access to dconf.

Currently, a contained app either has full read/write access to dconf, or no access. It should have read/write access to its own subtree(s) of dconf configuration space, and no access to the rest.

Allison suggested an API in which the dconf service creates a new *cursor* object, and asks dbus-daemon to open up access to that object for a particular container instance.

(If it was just about method calls, we could require dconf to implement this itself. However, dconf sends broadcasts, and we want to lock those down too.)

Snap developers suggested that the Containers1 API should be usable for MAC as well as for DAC. To support that, we might want to have this be an opt-in feature, where rules added by dconf or similar only take effect if the container manager has opted-in to "can grant access". (Or we might want to decide that Containers1 is DAC, and tell Snap developers that if they want MAC they need to stick to AppArmor.)

[ ] New message filtering rules can be added by unconfined peers at runtime
[ ] Contained peers cannot alter message filtering rules
[ ] Peers can revoke exact access rules that they added (by making a method call with identically-matching parameters, or with a cookie that was returned when the rule was added, or something)

Out of scope

* Peers are not required to be able to revoke access rules by any more complex match rule than an exact one
* Peers are not required to be able to revoke access rules that were added at creation (the Allow parameter from Bug #101902), although it might also be acceptable if they can
Comment 1 GitLab Migration User 2018-10-12 21:34:31 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/206.

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.