On Tue, Dec 11, 2012 at 7:04 PM, Pai Peng <[email protected]> wrote: > I have some questions about levelFromUid and mlstrustedsubject. My > understanding is that levelFromUid will add two categories to an app’s > context, such as “c1,c256”. MLS constraints make sure a subject cannot > access an object with “c1, c256” if itself doesn’t contain “c1” and “c256”, > unless it is a mlstrustedsubject. But the subject with “c1, c256” should be > able to access an object without any categories.
It should be able to read such an object, but not write to it unless the object is a mlstrustedobject. The usual MLS rules are no-read-up and no-write-down, with category sets ordered by the subset relation. > When I look at seapp_contexts, only untrusted_app has levelFromUid=true. So > only untrusted_app will have the added categories. MLS constraints will not > deny untrusted_app to access files of platform_app, release_app, and etc. > This seems a little weird since the files of platform_app and other apps are > not protected from untrusted_app. Actually it seems the policy wants > untrusted_app to access those files since untrusted_app is put into > appdomain. So do we only want app isolation between untrusted_apps? > > > > Also, why only platform_app is given the mlstrustedsubject attribute? Is it > because only platform_app may need to access files of untrusted_app > sometime? We originally set levelFromUid=true for all app domains. However, CTS testing indicated that this is problematic for Android; there are various cases where Android apps engage in intentional file sharing. We tried to work around this by distinguishing direct open of another app's files by pathname vs. receiving an open file descriptor from the app (note the different constraints in mls for app_data_file), but even this was insufficient to address all cases. So we backed off to only setting levelFromUid=true for third party apps. The platform apps then need to be mlstrustedsubjects so that they can act on files created by the third party apps and passed via Binder. We recently introduced changes to libselinux and sepolicy to generalize the levelFromUid support for the recent Android multi-user support, so that you can choose instead to assign unique category sets per-user, per-app, or per-combination. Per-user assignment may be a better path for SELinux level isolation as there is less sharing there and we have fewer legacy constraints. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
