On 1 February 2017 at 22:46, Jamie Strandboge <[email protected]> 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. -- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
