Snap security questions

[James Henstridge]

On 1 February 2017 at 22:46, Jamie Strandboge <jamie at canonical.com> wrote:
> On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote:
>> 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.

Since it looked like we'd need a specialised snappy interface for
thumbnailer, I had a go adding the rules necessary to enable
aa_query_label() there.  If thumbnailer turns out to be the only snap
needing this API, or the other snaps needing it also require custom
interfaces, then perhaps this is a reasonable place to put the rules.

Of course, once I got my interface up and running, I ran into
https://bugs.launchpad.net/apparmor/+bug/1620635 again.  I've put my
in-progress branch up for review here:

https://github.com/snapcore/snapd/pull/2783


>> 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).

As Tony noted, there was no Qt patch on Touch.  In retrospect it is
obvious why I hadn't seen the denials there though: we hadn't yet
tried to confine the daemon there.

A quick scan through the log files on my phone shows instances of the
denial for other confined apps, so I guess this is probably harmless.

I suspect this will cause other people confusion though: if your app
starts spitting out warnings about not being able to talk to
NetworkManager, the first instinct is going to be to plug into the
"network-manager" interface, and that is going to be the wrong option
most of the time.

James.