Snap security questions

[Jamie Strandboge]

On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote:
> Hi,
> 
> On our team we've been working to snap the thumbnailer project.  While
> there are some problems that are probably specific to this package,
> there were a few that I suspect might affect other packages too:
> 
> 1. Intra-snap D-Bus communication
> 
> The thumbnailer D-Bus service exposes a number of methods that were
> intended for use by the "thumbnailer-admin" helper program, but not by
> outside clients.  The generic "dbus" snappy interface does a good job
> of making sure clients can't call these privileged methods, but I'm
> left needing a way to get thumbnailer-admin working again.
> 
> I noticed that the default AppArmor rules allow communication via unix
> domain sockets with other apps from the same snap, so one easy way to
> solve my problem would be to also allow applications to send and
> receive arbitrary messages over the session bus to/from other
> applications from the same snap.  This would let me get
> thumbnailer-admin working without having to expose the same abilities
> to third party snaps through a slot.
> 
> I filed a bug about this one here:
> 
> https://bugs.launchpad.net/snappy/+bug/1659724
> 
I was thinking about this one myself. Thanks for filing the bug. I've assigned
it to me.

> 
> 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs
> 
> When deciding whether to do work on behalf of a client,
> thumbnailer-service uses a couple libapparmor API calls to determine
> whether the client has access to a file.  Neither of these are working
> under snappy confinement.
> 
> The first call we use is aa_is_enabled(), but it seems the policy is
> to strict to let us determine whether AppArmor is enabled or not.
> 
> Next we use aa_query_label() to perform the file access check.  This
> fails when trying to read /proc/$pid/mounts to determine where
> securityfs is mounted.  If that is fixed, it will likely fail when
> trying to access the "/sys/kernel/security/apparmor/.access" file
> within.
> 
> I've filed a bug for this one here:
> 
> https://bugs.launchpad.net/snappy/+bug/1660957

This needs some more thought since only "trusted helpers" that are doing some
form of mediation themselves need this access. Adding it to the dbus interface
by default isn't correct since, for example, ktuberling shouldn't be asking
about the security contexts of other snaps (not to mention, this doesn't really
have anything to do with the dbus interface). I've assigned it to me and will
think about it and will comment in the bug/propose a PR where we can discuss
further.

> 
> 3. QNetworkAccessManager wants to access NetworkManager
> 
> We use QNetworkAccessManager as our HTTP library.  This results in a
> number of denials for D-Bus method calls to NetworkManager.
> 
> I can make these denials go away by plugging in to the
> ":network-manager" slot, but a quick look at that interface shows that
> it grants a lot more permissions than I need or want (i.e. permission
> to reconfigure the network).
> 
> I imagine that a lot of snaps will use QNetworkAccessManager, so it
> would be nice if the calls it makes were allowed by some
> auto-connectable interface.  If not as part of ":network", then
> something similar.

The network-manager API is highly privileged (and messy) and should not be auto-
connected. Most applications that use network manager are only trying to figure
out if they are online or not, but the way to do that in the network manager API
is to query a ton of things a confined app shouldn't typically have. This is
what Qt does by default and this is why the connectivity-api was developed and
used on Touch[1]. connectivity-api is proxy that can answer questions like "am I
online" on behalf of the application. On Touch, iirc, Qt was modified to use
connectivity-api so Touch apps transparently used connectivity-api behind the
scenes. AIUI, the Personal team is in the process of creating the connectivity-
api snap and I suspect this'll work when using ubuntu-platform content snap
(Personal team, please correct me if I mispoke). Once connectivity-api works as
a snap, the plan is to make the connectivity-api accesses in an interface that
is auto-connectable (you might check with the Personal team on the status of all
this connectivity-api work).  

[1]GNOME has recently created the Network Monitor portal for this as well. It
isn't snapped yet, but I see no reason why why it couldn't be with an interface 
created for it

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170201/883e57e3/attachment.sig>