ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

Pulling into CC various stakeholders.

On 11/12/2014 09:47 AM, Florian Boucault wrote:
> Hello all,
> 
Hi!

> The camera and the gallery app today are authorized to read/write in
> /home/$USER/Pictures and /home/$USER/Videos.
> Soon they will also need to be able to read/write in the similar directories of
> the SD card, for example:
> - /media/phablet/064a-7494/Pictures
> - /media/phablet/064a-7494/Videos
> 
> I was wondering if there were any plans/ideas to make that possible in the near
> future.
> A bug report was created to track progress on
> it: https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1391930
> 

We have discussed this in the past, but the implementation was decided to not be
for RTM, since it is a complex topic. This is long, but I think forms the basis
of a specification.

A couple of important things to note:

 * A firm requirement is that we need to make sure that SD card access is done
   safely and that we do not open this up to be a big shared storage area like
   android did (they are trying to fix this now).
 * It might be helpful to divide the directories on the SD card into
   categories: 'global' (eg, Pictures, Videos, Music, etc) and 'app specific'

*If* we can guarantee that the mountpoint will be:
  /media/$USER/$SDCARD_ID/...

*only then* we can create a predictable hierarchy for the so called global
directories like so:
  /media/$USER/$SDCARD_ID/Music
  /media/$USER/$SDCARD_ID/Pictures
  /media/$USER/$SDCARD_ID/Videos

With the above in place, Then we can do things like this in the various existing
reserved AppArmor policy groups (ie, music_files, picture_files, video_files, etc):
  owner /media/*/*/Music/      r,
  owner /media/*/*/Music/**    rwk,
  owner /media/*/*/Pictures/   r,
  owner /media/*/*/Pictures/** rwk,
  owner /media/*/*/Videos/     r,
  owner /media/*/*/Videos/**   rwk,

This would solve the camera and gallery use case since the camera and gallery
are allowed to use these reserved policy groups.


We can then do something similar for apps. Eg, the predictable hierarchy for
apps might be:
  /media/$USER/$SDCARD_ID/.cache/$APP_PKGNAME
  /media/$USER/$SDCARD_ID/.config/$APP_PKGNAME
  /media/$USER/$SDCARD_ID/.local/share/$APP_PKGNAME

such that the AppArmor templates add:
  owner /media/*/*/.cache/@{APP_PKGNAME}/         rw,
  owner /media/*/*/.cache/@{APP_PKGNAME}/**       mrwkl,
  owner /media/*/*/.config/@{APP_PKGNAME}/        rw,
  owner /media/*/*/.config/@{APP_PKGNAME}/**      mrwkl,
  owner /media/*/*/.local/share/@{APP_PKGNAME}/   rw,
  owner /media/*/*/.local/share/@{APP_PKGNAME}/** mrwklix,


Observations:
 * the above essentially recreates a subset of the same predictable directory
   hierarchy in $HOME in /media/$USER/$SDCARD_ID
 * if we agree on the above, we actually may not have to change the policy
   groups and templates: we could create /etc/apparmor.d/tunables/home.d/sdcard
   to have:
     @{HOMEDIRS}+=/media/*/*/
   this is an implementation detail that would need to be investigated, but it
   would provide flexibility for if we ever want to change the mountpoint
 * media-hub and mediascanner would need to be updated for the above (since we
   don't have the AppArmor file query interface yet)


** IMPORTANT limitation **
SD cards are often formatted as vfat for wide OS support. vfat does not have a
concept of UIDs. AppArmor does not have user profiles and our current
implementation has one AppArmor profile per installed version of an app such
that there is one profile for the camera app that both user1 and user2 will use.
All together, this means that on a multiuser system, there won't be proper
separation of data. Ie: if have these paths:
   /media/user1/064a-7494/Pictures
   /media/user2/064a-7494/Pictures

then user1 can access user2's Pictures and user2 can access user1's Pictures
because the 'owner' part of the AppArmor rule won't be able to differentiate
between the two. In other words, while the above provides good separation
between apps and should work well on a single user system, it fails with
multiuser due to limitations of the vfat filesystem.

How to deal with this? A couple of things come to mind:
 * we format with a filesystem that supports UIDs. Perhaps we could prompt the
   user with a choice-- format for wide compatibility and secure single user, or
   format for reduced compatibility and secure multiuser. This has usability
   concerns.
 * we do the above and punt on multiuser SD card support since multiuser on
   an SD card doesn't make a lot of sense anyway. This has security concerns.
 * adjust AppArmor to support per user profiles. This is planned but a year or
   more off.
 * adjust to have different AppArmor system profiles per user. Eg,
   com.example.foo_app_version might be user1_com.example.foo_app_version. This
   would be amazingly disruptive (and I sorta wish I didn't mention it) since
   the profile name is the APP_ID which is used everywhere. Also, it is
   unnecessarily resource intensive the more users you have and ultimately may
   not even be possible to pull of securely with the way that click hooks work.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature