gsettings doesn't work with snap confinement

[Sebastien Bacher]

Work is needed there, see https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement#GSettings.2Fdconf

[Sebastien Bacher (seb128)]

Jamie suggested that we might allow it on classic as a known limitation

[Jamie Strandboge (jdstrand)]

Note, there is planned work for proper gsettings and AppArmor integration, but that didn't land in 16.04. This bug is about adding access to global gsettings as part of the transition unity7 policy (much like we allow access to the unity7 APIs, X, etc).

[Jamie Strandboge (jdstrand)]

FYI, this would allow gsettings to be used:

# Unrestricted access to gsettings. This is an information leak and allows
# tampering with settings from other apps. This will be fixed when
# gsettings/AppArmor mediation is completed.
#include <abstractions/dconf>
owner /{,var/}run/user/*/dconf/user w,
owner @{HOME}/.config/dconf/user w,
dbus (receive, send)
    bus=session
    interface="ca.desrt.dconf.Writer"
    peer=(label=unconfined),

However I'm not excited about adding that to the policy for the reasons stated in the comment. I'm aware of gsettings and apparmor mediation that would fix this and perhaps it can be prioritized for 16.10 (pending stakeholder process) and eventually SRUd, but if we allow this now and apps use it we can't easily undo it.

The applications appears to without it even though there are many denials. Have you considered:
* I know dconf has multiple backends-- is it possible to use a different backend
* have dconf use SNAP_USER_DATA as the prefix instead of HOME
* set HOME to SNAP_USER_DATA as part of the 'calc' wrapper script?

[Sebastien Bacher (seb128)]

Having another gsettings backend is possible I guess, but we would need to write that code and we might as well invest the effort on the proper solution/proxy...

Your comment made me think about it a bit more though and adding the dbus permissions isn't going to resolve the issue. It would let the application reach the service and write changes to the system db but the reads are done by mmaping the file so the applications wouldn't to read anything back.

We could have a dconf db in the snap and tweak environment, but then we would need to have an another dbus session bus and private dconf instance inside the snap....

[Jamie Strandboge (jdstrand)]

AIUI people should be using --devmode to work around confinement problems while proper interfaces are in place, so I think at this most basic level, people should be unblocked (at least in terms of security policy).

To set the context for this discussion: the good news is that proper gsettings mediation work is underway with both upstream, the security and the desktop teams being involved. Unfortunately, for the security team this work is behind phase 1 of apparmor stacking work in support of LXD. Most of that work has landed and is in 16.04, but a number of bugs need to be addressed by 16.04.1 and the developer tasked with gsettings mediation is still focused on this LXD stacking work and unless the stacking work is deprioritized, the gsettings mediation will not be picked up for a while.

If --devmode is deemed insufficient while we wait for the gsettings work to recommence, we can:
1. add a new reserved 'gsettings-global' (actual name TBD) interface that does not auto-connect. This would allow unrestricted read/write access to the global gsettings database in the user's session
2. when gsettings mediation lands, add app-specific gsettings access to the unity7 interface
3. adjust the 'gsettings-global' interface for the gsettings mediation (eg, add the bare 'gsettings,' rule)

My feeling is '1' will be useful/required for certain applications and it can remained a privileged interface once we have gsettings mediation so this wouldn't be wasted effort if people feel it would help.

[Mark Shuttleworth (sabdfl)]

On 17/05/16 12:02, Jamie Strandboge wrote:
> If --devmode is deemed insufficient while we wait for the gsettings work to recommence, we can:
> 1. add a new reserved 'gsettings-global' (actual name TBD) interface that does not auto-connect. This would allow unrestricted read/write access to the global gsettings database in the user's session
> 2. when gsettings mediation lands, add app-specific gsettings access to the unity7 interface
> 3. adjust the 'gsettings-global' interface for the gsettings mediation (eg, add the bare 'gsettings,' rule)

(3) would be my recommended approach.

We should not let perfect be the enemy of good. We would LIKE to have a
mediated gsettings, but we MUST unblock gsettings apps. Therefor, for
series 16, we can have a general "gsettings" interface which is not
mediated. We can add mediation and a more refined interface during
series 16, and deprecate the general interface for series 18.

Make sense?

Mark

[Oliver Grawert (ogra)]

note that there are a few apps that actually store passwords in gsettings (rhythmbox (for LAN sharing), shotwell (upload passwords for piwigo service), evolution (proxy password).

couldn't we have a very simple global filter on the interface side of things as interim solution ?
the snap knows what key it wants to get/set, the interface handler should just block any other call to gsettings not using this key.

[Jamie Strandboge (jdstrand)]

@Oliver - that is the plan. The gsettings/apparmor mediation I am referring to is not simply 'you can access gsettings', it is 'you can access these gsettings keys' and like everything else, that will be default deny and we'll only allow app-specific keys and read only access to safe global keys.

@Mark - yes, though my list was a series of steps not options. :) You picking '3' is clear though-- unblock people now with an interface that allows access to gsettings, work on full mediation and SRU that. Thanks!

[Sebastien Bacher (seb128)]

dconf also needs access to the system /run/user/<uid>/dconf directory to work

[Mark Shuttleworth (sabdfl)]

On 18/05/16 08:34, Jamie Strandboge wrote:
> @Mark - yes, though my list was a series of steps not options. :) You
> picking '3' is clear though-- unblock people now with an interface that
> allows access to gsettings, work on full mediation and SRU that. Thanks!

Please take this as general guidance - sledgehammer interfaces are fine
in Core 16. We can make them require review once we have more
fine-grained interfaces.

Mark

[Jamie Strandboge (jdstrand)]

This is in 2.0.7 (2.0.8 is in proposed).

[Sebastien Bacher (seb128)]

gsettings still doesn't work confined because XDG_RUNTIME_DIR is not available in the snap environment...

[Sebastien Bacher (seb128)]

sorry for the previous comment, I tested wrongly, it seems to work but ironically to updated value is reflected outside of the snap but not in the snap (the session session writes in the db which is in the real user directory and not in the private snap one, where the snap confined binary is trying to read from then...)

[Jamie Strandboge (jdstrand)]

This bug is about the security policy related to accessing global gsettings. That policy has been added and is available in 2.0.7 and 2.0.8 is available in xenial-updates now, so marking Fix Released. yakkety is still at 2.0.2 with 2.0.9 in yakkety-proposed so marking Fix Committed.

Seb and I discussed on IRC the issue he was facing that prompting the change to the bug status, so reverting his changes. There is work to do for the snap to find the session gsettings files due to how HOME is set, but the security policy allows it now. Please file a new bug if something needs to change in snapd for this issue. Thanks!

[Sebastien Bacher (seb128)]

Right, sorry for the confusing. the dbus access to the dconf service and the xdgruntime are working as they should, what is confusing the gsettings client is that the database is not in the standard ~/.config.

Ideally we would bindmount the host ~/.config/dconf/user to the snap private location but until we get
bindmount interfaces we can probably get away by giving access to the real userdir and creating a symlink in the launcher script.

[Jamie Strandboge (jdstrand)]

This is fixed in snapd 2.11+16.10 on Ubuntu 16.10.