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/
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
