please integrate mediascanner2 and media-hub with apparmor

Bug #1303962 reported by Jamie Strandboge on 2014-04-07
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Thumbnailer
Fix Released
Undecided
Unassigned
apparmor-easyprof-ubuntu (Ubuntu)
High
Jamie Strandboge
media-hub (Ubuntu)
Undecided
Unassigned
media-hub (Ubuntu RTM)
Undecided
Unassigned
mediascanner2 (Ubuntu)
High
James Henstridge

Bug Description

media-hub and mediascanner are separate processes from apps and are used to play and scan music and video files respectively. Up until now, apps would have to use the music_files_read or video_files_read reserved policy groups to access media. The problem is, these policy groups are reserved and not available to normal AppStore apps in order to prevent information leaks (this user has this video installed) and theft (can access the music and video directly). The path forward is that media-hub and mediascanner are helpers that apps can use and they should integrate with the trust store.

AppStore apps:
 1. should be able to access their own content (installed or local)
 2. should not be able to access, play or otherwise enumerate other apps' media (ie, app 'foo' should not be able to play the facebook app's sound file
 3. AppStore apps should be able to enumerate the global music (~/Music) and video (~/Video) library via the mediascanner helper with permission from the user
 4. AppStore apps should be able to play the global music (~/Music) and video (~/Video) library via the media-hub with permission from the user
 5. AppStore apps should be able to have access to media files with permission from the user. This is already handled by the content-hub paradigm (though someone would need to add a media content provider for the content-hub to have this work)

Both media-hub and mediascanner should do something like the below pseudo code:

# see 'man aa_getcon()' from libapparmor-dev for more info
# conn_name is the unique D-Bus connection name of the application connecting
# to media-hub/mediascanner
apparmor_profile = org.freedesktop.DBus.GetConnectionAppArmorSecurityContext(conn_name)

pkgname = apparmor_profile.split('_')[0]
if apparmor_profile == unconfined: # unconfined apps can access all the files
    allow access
elif playback_file in ~/.local/share/$pkgname/... or playback_file in ~/.cache/$pkgname/..: # apps can access their own files
    allow access
elif $pkgname can access playback_file in trust store: # apps can access the files if user said so previously
    allow access
elif playback_file in ~/Music:
    answer = prompt user for access to global music files
    if $answer == yes
        update trust store for $pkgname can enumerate/play ~/Music
        allow access
    else:
        deny access
elif playback_file in ~/Videos:
    answer = prompt user for access to global video files
    if $answer == yes
        update trust store for $pkgname can enumerate/play ~/Videos
        allow access
    else:
        deny access
else:
    deny access

To have the best user experience and prevent multiple prompting, mediascanner and media-hub should use the same trust store database. I'm not sure that mediascanner2 offers a DBus API for enumerating global media files yet or not (music-app seems to be accessing files in ~/.cache/media-art/ and ~/.cache/mediascanner directly).

UPDATE: 2014-05-02
media-hub implemented '1' and '2' already (can access its own data, but not other apps' data) and was marked Fix Released. Trust store integration ('3' and '4') is now being tracked in bug #1315381.

mediascanner2 still needs to implement '1' and '2'. The 'audio' and 'video' policy groups will *not* add this access at this time. Instead, apps can use 'read_path' as part of their policy to have access to the mediascanner files. This is workable for the music app, but will block other apps from inclusion in the app store.

Related branches

description: updated
description: updated
tags: added: application-confinement
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: New → Confirmed
Changed in mediascanner2 (Ubuntu):
importance: Undecided → High
Changed in apparmor-easyprof-ubuntu (Ubuntu):
importance: Undecided → High
description: updated
Marc Deslauriers (mdeslaur) wrote :

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

description: updated
Tyler Hicks (tyhicks) on 2014-04-07
description: updated
Jamie Strandboge (jdstrand) wrote :

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.

Jim Hodapp (jhodapp) on 2014-04-14
Changed in media-hub:
assignee: nobody → Jim Hodapp (jhodapp)
importance: Undecided → High
status: New → In Progress
Changed in mediascanner2 (Ubuntu):
status: New → Confirmed
Jim Hodapp (jhodapp) on 2014-04-15
Changed in media-hub:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Confirmed → Fix Released
summary: - please integrate mediascanner2 and media-hub with trust-store
+ please integrate mediascanner2 and media-hub with apparmor
description: updated
description: updated
Jussi Pakkanen (jpakkane) wrote :

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.

James Henstridge (jamesh) wrote :

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

James Henstridge (jamesh) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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

Jussi Pakkanen (jpakkane) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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?

James Henstridge (jamesh) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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?

Changed in mediascanner2 (Ubuntu):
status: Confirmed → Fix Released
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Fix Released → In Progress
James Henstridge (jamesh) wrote :

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.

Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in mediascanner2 (Ubuntu):
assignee: nobody → James Henstridge (jamesh)
Launchpad Janitor (janitor) wrote :

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

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: In Progress → Fix Released
Victor Thompson (vthompson) wrote :

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

Jamie Strandboge (jdstrand) wrote :

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

Jussi Pakkanen (jpakkane) wrote :

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)

Jamie Strandboge (jdstrand) wrote :

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.

James Henstridge (jamesh) wrote :

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.

Michi Henning (michihenning) wrote :

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.

Changed in thumbnailer:
status: New → Fix Committed
Changed in thumbnailer:
status: Fix Committed → Fix Released
Jim Hodapp (jhodapp) on 2015-11-18
Changed in media-hub (Ubuntu):
status: New → Fix Released
no longer affects: media-hub
Changed in media-hub (Ubuntu RTM):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers