Add download manager interface #2328

Merged
merged 19 commits into from Jan 18, 2017

Conversation

Projects
None yet
6 participants
Contributor

Elleo commented Nov 22, 2016

Add an interface that allows download manager clients to talk to a confined ubuntu-download-manager service. This also introduces the SNAP_LABEL_DBUS template variable which is required by UDM for creating application specific dbus paths.

The plug app armor rules are based on the original click rules, however the slot rules are new as UDM was previously unconfined on click systems.

Remove the legacy auto connect stuff (it was removed in master now) and let's see what the security team think about this.

interfaces/apparmor/template_vars.go
var buf bytes.Buffer
fmt.Fprintf(&buf, "@{SNAP_NAME}=\"%s\"\n", info.Name())
fmt.Fprintf(&buf, "@{SNAP_REVISION}=\"%s\"\n", info.Revision)
+ fmt.Fprintf(&buf, "@{SNAP_LABEL_DBUS}=\"%s\"\n",
@zyga

zyga Nov 22, 2016

Contributor

I see why we're doing this but I don't know what @jdstrand will think about it.

@jdstrand

jdstrand Dec 5, 2016

Contributor

@zyga, I recommended it we bring it back. It was one of variables that was removed because nothing used it yet. We agreed then that we'd reintroduce it when Personal came along, since trusted helpers on Personal will use the DBusified security label as part of their DBus API.

That said, SNAP_LABEL_DBUS sounds a little weird. I know why it is named this way: it is the full security label of the process as a dbus string. AppArmor itself understands the '@{profile}' variable and expands it to the security label of the process. I think '@{PROFILE_DBUS} might be better in that light. What do others think?

interfaces/builtin/basedeclaration.go
+ allow-installation:
+ slot-snap-type:
+ - app
+ deny-auto-connection: false
@zyga

zyga Nov 22, 2016

Contributor

@jdstrand should this be true so that it can be overridden with a snap declaration assertion from the store?

interfaces/builtin/download.go
+ return nil
+}
+
+func (iface *DownloadInterface) LegacyAutoConnect() bool {
@zyga

zyga Nov 22, 2016

Contributor

We don't need LegacyAutoConnect anymore, please remove it.

interfaces/builtin/download_test.go
+ c.Assert(snippet, Not(IsNil))
+}
+
+func (s *DownloadInterfaceSuite) TestLegacyAutoConnect(c *C) {
@zyga

zyga Nov 22, 2016

Contributor

Please remove this as well.

Elleo added some commits Nov 22, 2016

zyga approved these changes Nov 22, 2016

Looks better, thanks. Do get a +1 from @jdstrand before landing please.

interfaces/apparmor/template_vars.go
var buf bytes.Buffer
fmt.Fprintf(&buf, "@{SNAP_NAME}=\"%s\"\n", info.Name())
fmt.Fprintf(&buf, "@{SNAP_REVISION}=\"%s\"\n", info.Revision)
+ fmt.Fprintf(&buf, "@{SNAP_LABEL_DBUS}=\"%s\"\n",
@zyga

zyga Nov 22, 2016

Contributor

I see why we're doing this but I don't know what @jdstrand will think about it.

@jdstrand

jdstrand Dec 5, 2016

Contributor

@zyga, I recommended it we bring it back. It was one of variables that was removed because nothing used it yet. We agreed then that we'd reintroduce it when Personal came along, since trusted helpers on Personal will use the DBusified security label as part of their DBus API.

That said, SNAP_LABEL_DBUS sounds a little weird. I know why it is named this way: it is the full security label of the process as a dbus string. AppArmor itself understands the '@{profile}' variable and expands it to the security label of the process. I think '@{PROFILE_DBUS} might be better in that light. What do others think?

interfaces/builtin/basedeclaration.go
+ allow-installation:
+ slot-snap-type:
+ - app
+ deny-auto-connection: true
@jdstrand

jdstrand Dec 5, 2016

Contributor

My understanding of UDM is that its DBus is considered completely safe for anyone to use. As such, this should drop 'deny-auto-connection: true'. Because it is is slot implementation, it should have 'deny-connection: true' to be in line with our current implementation.

Note that the use of 'deny-connection' is actively being discussed and we may change this. When developing this interface, please also note https://bugs.launchpad.net/snappy/+bug/1640874.

interfaces/builtin/download.go
+ bus=session
+ interface=com.canonical.applications.DownloadManager
+ member=setDefaultThrottle,
+`)
@jdstrand

jdstrand Dec 5, 2016

Contributor

The way snappy stitches together, explicit deny rules are problematic. Please instead remove these explicit denies and simply document that allowGSMDownload, createMmsDownload, exit and setDefaultThrottle are intentionally left out of downloadConnectedPlugAppArmor since they are privileged. Perhaps we can use an attribute or new interface (eg, download-manager-control) when snaps need access to these privileged methods.

interfaces/builtin/download.go
+ interface=com.canonical.applications.DownloadManager
+ member=downloadCreated
+ peer=(label=unconfined),
+`)
@jdstrand

jdstrand Dec 5, 2016

Contributor

I expected these to use label=###PLUG_SECURITY_TAGS### but you have label=unconfined. Can you explain? Is this for talking to applications shipped as debs on classic?

@Elleo

Elleo Dec 13, 2016

Contributor

It was used for allowing the transfer-indicator to monitor downloads from other apps, but that would only have applied on a unity8 deb desktop. In the unity8 snap currently UDM and the transfer-indicator will be in the same snap so it won't matter, and if UDM gets split out at some point I think it'd be best to add a new restricted interface for "download-manager-observer" or similar; so I've removed them for now.

interfaces/builtin/download.go
+
+# dbus
+connect
+getsockname
@jdstrand

jdstrand Dec 5, 2016

Contributor

getsockname is part of the default template.

interfaces/builtin/download.go
+
+# dbus
+connect
+getsockname
@jdstrand

jdstrand Dec 5, 2016

Contributor

Ditto

interfaces/builtin/download.go
+type DownloadInterface struct{}
+
+func (iface *DownloadInterface) Name() string {
+ return "download"
@jdstrand

jdstrand Dec 5, 2016

Contributor

I think this is far too generic for an interface name since 'network' allows you to 'download' things. Perhaps 'download-manager'? @niemeyer - what are your thoughts?

interfaces/builtin/download.go
+
+# Allow writing to app download directories
+owner @{HOME}/snap/*/common/Downloads/ rw,
+owner @{HOME}/snap/*/common/Downloads/** rwk,
@ted-gould

ted-gould Dec 8, 2016

Seems like the download manager should only get access to the directories of snaps that are connected. So this should be a per-slot connection with the name of the package in it.

@jdstrand

jdstrand Dec 8, 2016

Contributor

That is an excellent point @ted-gould. Thanks!

Elleo added some commits Dec 12, 2016

A coupled of nit picks and a question regarding the system bus. If you remove the system bus access, +1, otherwise need to look into that further.

interfaces/builtin/download_manager.go
+ are deliberately left out of this profile due to their privileged nature. */
+var downloadConnectedPlugAppArmor = []byte(`
+# Description: Can access the download manager.
+# Usage: common
@jdstrand

jdstrand Dec 13, 2016

Contributor

With the base declaration, all these 'Usage' metatags can be dropped.

interfaces/builtin/download_manager.go
+# Description: Can access the download manager.
+# Usage: common
+
+#include <abstractions/dbus-strict>
@jdstrand

jdstrand Dec 13, 2016

Contributor

I just noticed this. Why do you need access to the system bus? All your apparmor rules are for the session bus.

interfaces/builtin/download_manager.go
+# Usage: common
+
+# DBus accesses
+#include <abstractions/dbus-strict>
@jdstrand

jdstrand Dec 13, 2016

Contributor

Why do you need access to the system bus here and in the communications with dbus-daemon?

interfaces/builtin/download_manager.go
+# Allow writing to app download directories
+owner @{HOME}/snap/###PLUG_NAME###/common/Downloads/ rw,
+owner @{HOME}/snap/###PLUG_NAME###/common/Downloads/** rwk,
+
@jdstrand

jdstrand Dec 13, 2016

Contributor

Please remove this empty line.

Contributor

jdstrand commented Dec 13, 2016

One other thing: please get sign-off on 'download-manager' as the name of the interface from @niemeyer

Elleo added some commits Dec 14, 2016

Contributor

jdstrand commented Dec 15, 2016

Thanks for making these changes. Approving, but please get signoff from @niemeyer on the interface name 'download-manager'.

chipaca added some commits Jan 16, 2017

chipaca added some commits Jan 18, 2017

@chipaca chipaca merged commit 8251637 into snapcore:master Jan 18, 2017

5 of 6 checks passed

yakkety-amd64 autopkgtest finished (failure)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
xenial-amd64 autopkgtest finished (success)
Details
xenial-i386 autopkgtest finished (success)
Details
xenial-ppc64el autopkgtest finished (success)
Details
zesty-amd64 autopkgtest finished (success)
Details
Contributor

Elleo commented Jan 18, 2017

The name unity8-download-manager seems a bit odd to me? Surely we don't want the download-manager to always be restricted to only being a unity8 service, otherwise we're disincentivising developers to make use of it in their applications since they wouldn't want them tied to a single desktop environment?

Contributor

niemeyer commented Jan 18, 2017

Can you please raise this topic on the snapcraft list? A similar naming scheme was used on unity8-calendar and unity8-contacts, so we need to either undo those as well or establish a different pattern which may be used for all of them.

The counter argument to "download-manager" is that this is an extremely general name, rather than a noun associated with a particular piece of software. So it ends up being a poor name to the interface as well.

Member

chipaca commented Jan 18, 2017

Ah, my apologies. As you were requested to raise the issue with Gustavo a month ago and didn't, I talked with him myself and it seems I misrepresented the project.

Member

chipaca commented Jan 18, 2017

@niemeyer note the unity8-calendar and -contacts names were chosen (moved away from eds iirc) because they were very specific for unity8 scopes AFAIR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment