Snap security questions

James Henstridge james.henstridge at canonical.com
Wed Feb 1 12:33:50 UTC 2017


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


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


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.


James.




More information about the Snapcraft mailing list