ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 2014-11-12 11:58 AM, Jamie Strandboge wrote:
> 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).

Yes, this needs to be an intermediate solution only until proper storage support
is added, and should be restricted to certain trusted applications. We do not
want apps to be able to use this as a place to exchange data amongst themselves.

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

That sounds acceptable.

> 
> 
> 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,

This is problematic. As you mention later on, sdcards mostly use vfat, which
means file names are case insensitive. This opens up a lot of issues when trying
to confine apps to specific directories, and also creates issues with data loss
if the system isn't designed to cope well.

If we want app-specific directories on the sdcard, we will likely have to
require the card be formatted with a better filesystem, or we should punt on
this for now.

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

It unclear to me how this will be presented to the user...will they _know_ they
are accessing the sdcard when they take pictures? How are we going to implement
proper encryption at a later time if user data is going to be stores on the sdcard?

In all honestly, I think the sdcard probably needs to be a completely separate
storage location that is exposed to the user.

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


Marc.