please integrate mediascanner2 and media-hub with apparmor

As a sidenote: we probably don't want the user's personal videos captured with the camera to be stored in the ~/Videos folder.

FYI, I just added rules to the reserved policy groups for music_files* and video_files* for media-hub and mediascanner files. music-app is still using mediascanner 1, so the mediascanner rules will almost certainly need to be updated. Note these rules were added so we could run the music-app confined, but these rules are not available to regular apps-- this bug will have to be fixed with media-hub and mediascanner adjusted to be trusted helpers before we can do that.

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.1.17

---------------
apparmor-easyprof-ubuntu (1.1.17) utopic; urgency=medium

  * 1.*/audio,video: allow communications with the media-hub-server now that
    it is a trusted helper (LP: #1303962)
  * 1.1/music_files*,video_files*: revert media-hub rules in 1.1.15 now that
    common policy groups (audio and video) can be used instead
  * 1.1/ubuntu-*: allow apps to communicate with the Launcher via their
    @{APP_ID_DBUS} specific path (LP: #1301400)
 -- Jamie Strandboge <email address hidden> Wed, 16 Apr 2014 13:40:03 -0500

Mediascanner2 does not index appstore apps' contents. It only deals with public information in ~/Music ~/Videos and mounted drives. It has nothing to do with the playback path, that is dealt entirely by media hub/music app.

There are three ways of accessing Mediascanner's stored data:

1. issue a scope query
2. use Mediascanner's Qml plugin
3. use libmediascanner (not recommended for most apps)

#2 is implemented using #3.

The only requirement to accessing data via 2 or 3 is to be able to have read-only access to ~/.cache/mediascanner-2.0/.

Mediascanner 2's scanner daemon of course needs write access to that directory as well as read rights to the directories that are to be scanned.

To me as non-security-specialist this seems to fullfill the requirements listed in the issue. If there's something I missed, please let me know.

The ~/.cache/media-art/ accesses should be gone when music-app converts to the new API: we're directing access via D-Bus helper now.

We don't have any AppArmor integration for that helper though. I'm not sure whether we'd need any user prompts though, since the data returned by the helper is entirely dependent on the input (artist and album names).

As a follow-on, here is the introspection data for the thumbnailer D-Bus service:

http://bazaar.launchpad.net/~unity-team/thumbnailer/trunk/view/head:/src/service/dbus-interface.xml

The file data is returned by passing a read-only file descriptor for a file in ~/.cache/media-art, and the content of that file is only dependent on the artist and album name in the method call.

Jussi and I discussed this quite a bit this morning. He explained that this is the process:
1. mediascanner2 scans files on the filesystem (eg, ~/Music and ~/Videos) and stores paths, file metadata (artist, album, etc) in ~/.cache/mediascanner2
2. apps use the QML plugin (which uses libmediascanner) to query the data in ~/.cache/mediascanner2
3. apps then can use the thumbnailer api to request the album via last.fm (this is cached on disk for later requests)

In '1', above, mediascanner2 runs unconfined and is a session service. It does not need any special consideration (though it should have an apparmor profile). In '2', the use of libmediascanner is in process to the app and therefore the app currently requires the reserved 'music_files_read/video_files_read' policy group otherwise an app can steal the mediascanner2 database for data mining, etc. For '3', there is no concern because the thumbnailer just fetches whatever it is told from last.fm (which the app could do itself).

What we need to protect is the scanned information in ~/.cache/mediascanner2 and access to ~/.cache/mediascanner2 should be considered privileged. DBus service should be created as a proxy to the data in ~/.cache/mediascanner2. This DBus service has direct access to ~/.cache/mediascanner2 and apps only have access to this DBus service (presumably via the QML plugin/libmediascanner). This service then becomes the trusted helper since it can perform the apparmor integration in this bug and the trust store integration in bug #1315381. Once this happens, this DBus api can be added to unprivileged policy groups (eg, audio/video).

It should be noted that there is one case which would break for third party music apps: album art embedded inside MP3 files. In order to read that the app would need read access to the actual music file.

The proper solution for this would be to expand the thumbnailer dbus service to also provide thumbnails for files and not just download album art based on artist and album. Unfortunately this is noticeably harder to get right, security-wise.

Regarding embedded album art: well, that is what the mediascanner is for no? An app can always read its own files (eg, a music app that downloads to its own directory) but if the file is stored in the global media collection (ie, ~/Music), then mediascanner can scan it, extract the album art and cache it. The app requests the metadata via libmediascanner which uses the aforementioned DBus API, the DBus service asks the user if it is ok (or pulls the previous answer from cache) and if it is ok, gives libmediascanner what it needs to then retrieve it from the thumbnailer (which in turn would get it from the mediascanner cache). Perhaps it is easier for the DBus service to give the scanned embedded album art to libmediascanner by passing an fd. Either way, it should fit the paradigm. Am I missing something?

So, with the 0.101+14.10.20140530-0ubuntu1 release now in the archive, mediascanner2's QML API now works through a D-Bus API. The D-Bus service checks its peer's AppArmor context and implements a rudimentary security policy (which I'd be happier with if I could delegate out to a central policy).

The easyprof profiles probably need updating to allow access to this D-Bus service though, since the music-app developers reported that they couldn't access it when running confined.

The audio and video policy groups have this for media-hub:
# Allow communications with media-hub
dbus (receive, send)
     bus=session
     path=/core/ubuntu/media/Service{,/**},

and this for thumbnailer:
# Allow communications with thumbnailer for retrieving album art
dbus (send)
     bus=session
     interface="org.freedesktop.DBus.Introspectable"
     path="/com/canonical/Thumbnailer"
     member="Introspect",
dbus (send)
     bus=session
     path="/com/canonical/Thumbnailer"
     member=GetAlbumArt,

What is needed for mediascanner2?

The MediaScanner 2 D-Bus interface is hooked up as:

name = com.canonical.MediaScanner2
path = /com/canonical/MediaScanner2
interface = com.canonical.MediaScanner2

There are only read-only methods made available through this interface, all of which call the security policy method. So it would be best to allow all methods on that interface.

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.2.4

---------------
apparmor-easyprof-ubuntu (1.2.4) utopic; urgency=medium

  * ubuntu/1.2: refinements to scopes policy
    - use private-files-strict abstraction
    - finetune client endpoint policy
    - explicitly deny access to the zmq directory for the ubuntu-sdk and
      ubuntu-webapp templates
    - explicitly deny direct interaction with URL dispatcher to prevent data
      leaks
    - move ubuntu-scope-local-content template to 'pending' since there are
      unresolved issues surrounding its interaction with URL dispatcher.
      Adjust autopkgtests accordingly
  * ubuntu/calendar: update for upcoming calendar management landing
  * ubuntu/*/audio,video: add mediascanner2 DBus access (LP: #1303962)
  * ubuntu/1.[12]/music_files_read: remove temporary access to
    @{HOME}/.cache/mediascanner/ now that we have policy for mediascanner2
    DBus access. Note: normally this would require the change in only the
    latest policy, but this policy group has only been used by the music-app
    and it is still unconfined
  * ubuntu/1.1: also ship debug policy group for 1.1 policy and update
    autopkgtests for this (LP: #1323233)
 -- Jamie Strandboge <email address hidden> Fri, 06 Jun 2014 07:37:54 -0500

Does Thaumbnailer still need apparmor integration? I believe it is blocking the music-app from going under confinement at the moment.

I believe mediascanner handles the thumbnailing and does not need any special confinement wrt music-app.

Mediascanner does not do thumbnailing at all. All of that is done by the thumbnailer library + service. Those should be confined already, but in case they are not, here's the skinny:

- there are two kinds of thumbnails: those created from files and those that are downloaded (album art)
- for files, thumbnailer uses the global cache for unconfined apps and app-local dir for confined apps so it should work for everyone
- to get album art thumbnails you need to be able to access the dbus service (which I think is available for all applications as it's read only)
- the dbus service needs to be able to access the net and write to the cache dir (which it already can do, otherwise no album art would ever show up)

Ok, so there is a thumbnailer service and apps using the audio policy group can already talk to it. Apps are also able to use libthumbnailer's vs-thumb under confinement, so I don't think that anything more needs to be done special for music-app. I will follow up with Jussi on if we need to add additional confinement to the service.

In case it helps, the thumbnailer's D-Bus interface is at:

Bus name: com.canonical.Thumbnailer
Path: /com/canonical/Thumbnailer
Interface: com.canonical.Thumbnailer

The method calls pass read-only file descriptors into a shared cache. The only art exposed via this interface at the moment is album and artist artwork, where the result is entirely dependent on the album and artist name passed to the method.

The music-app will need to be able to make calls to this service, but it should also be safe to make it more generally available.

The new thumbnailer uses apparmor queries to determine whether the caller is allowed to access the original file. If not, it denies access to the thumbnail too.