Hi Stephen,
Thank you for quick response. Here is my comments below: "I assume by this you mean adding the following in your device seapp_contexts file: user=system seinfo=platform isOwner=false domain=system_app type=system_app_data_file levelFrom=user Correct? That would turn on levelFrom=user for system UID apps running on behalf of secondary users but not for the primary/owner. At that point you also have the option of running those secondary user system app instances with a different domain/type than the owner instances, which could be useful if you want to make the owner mlstrusted but not the secondary instances." <Jinlin> It seems we do not need this feature. To define system_app/ system_app_data_file into different domain/type may cause neverallow conflict. "Why would it need to be mlstrustedsubject? That is only needed if applying levelFrom=user to system_app in user 0 so that it can write down to :s0-only files in /data outside of /data/data. But system apps running for secondary users can only write to their /data/user/N/<pkgdir> directory, so they shouldn't need this." <Jinlin> We are not sure if the data only be written to data/user/N/<pkgdir> directory for secondary user. Possibly they write the data to /data/data through Java API not Android API. "Currently system_app is not mlstrustedsubject, but system_app_data_file is mlstrustedobject. The latter was required to permit storing a user's profile photo, see: https://android-review.googlesource.com/#/c/130942/ So at the moment, even if you enable levelFrom=user on secondary users (isOwner=false), you won't get cross-user separation/protection of system app data files because they are exempted from the mls constraints. Alternatively, if we rewrote the mls constraint to only restrict open and not read/write on system_app_data_file (as we already do for app_data_file), then we wouldn't need to make system_app_data_file a mlstrustedobject, since that operation only requires passing an already open file over Binder, not a direct open. It should be noted that at least in AOSP policy, only system_app (among the app domains) can open system_app_data_file, so even if you have a world-readable file, it cannot be directly opened by e.g. untrusted_app, irrespective of categories. Whether or not that property is preserved in your policy I don't know; I don't think it is enforced via neverallow." <Jinlin> Thank you for clarification. We did not realize system_app_data_file is mlstrustedobject. We will make some adjustment accordingly. Regards, Jinlin -----Original Message----- From: Stephen Smalley [mailto:[email protected]] Sent: Tuesday, September 08, 2015 7:49 AM To: Jinlin Xu; [email protected] Cc: Dingbang Xu Subject: Re: possible approach for levelFrom=user On 09/04/2015 01:53 PM, Jinlin Xu wrote: > Hi Stephen, > > > > I have a question for you. > > In default Android-M, "levelfrom = user" is not applied into > system_app. But there is an alternative approach as you suggested in > the link http://marc.info/?l=seandroid-list&m=141150669811670&w=2.See below: > > > > - We could enable levelFrom=user for these apps*(<Added by me> such as > system app, nfc)*too, thereby running > > them with per-user levels like the other apps. However, this would > > break their interactions with system processes and resources unless we > > annotate those system domains and types with which they interact with > > mlstrustedsubject/object markings. > > > > With a little change from above words, I think the solution could be > even better than the one currently implemented in Android-M. > > > > - We could enable levelFrom=user for these apps*(<Added by me> such as > system app, nfc)*too, thereby running > > them with per-user levels like the other apps. However, this would > > break their interactions with system processes and resources unless we > > annotate those system domains and types with which they interact with > > mlstrustedsubject. For the system process data file in user 0, we set > no category markings (:s0 only). I assume by this you mean adding the following in your device seapp_contexts file: user=system seinfo=platform isOwner=false domain=system_app type=system_app_data_file levelFrom=user Correct? That would turn on levelFrom=user for system UID apps running on behalf of secondary users but not for the primary/owner. At that point you also have the option of running those secondary user system app instances with a different domain/type than the owner instances, which could be useful if you want to make the owner mlstrusted but not the secondary instances. > > > > Here is our comparison: > > > > Goal: Multiple Categorized Security Protection for AFW Managed > Profile > > Design Choices: > > 1. System App categorized in Managed Profile and not categorized in > user 0. > * Needs to define system app as mlstrustedsubject Why would it need to be mlstrustedsubject? That is only needed if applying levelFrom=user to system_app in user 0 so that it can write down to :s0-only files in /data outside of /data/data. But system apps running for secondary users can only write to their /data/user/N/<pkgdir> directory, so they shouldn't need this. > * System App world readable data in the managed Profile > *cannot be accessed*by the non_system app outside of the > managed profile Currently system_app is not mlstrustedsubject, but system_app_data_file is mlstrustedobject. The latter was required to permit storing a user's profile photo, see: https://android-review.googlesource.com/#/c/130942/ So at the moment, even if you enable levelFrom=user on secondary users (isOwner=false), you won't get cross-user separation/protection of system app data files because they are exempted from the mls constraints. Alternatively, if we rewrote the mls constraint to only restrict open and not read/write on system_app_data_file (as we already do for app_data_file), then we wouldn't need to make system_app_data_file a mlstrustedobject, since that operation only requires passing an already open file over Binder, not a direct open. It should be noted that at least in AOSP policy, only system_app (among the app domains) can open system_app_data_file, so even if you have a world-readable file, it cannot be directly opened by e.g. untrusted_app, irrespective of categories. Whether or not that property is preserved in your policy I don't know; I don't think it is enforced via neverallow. <Jinlin> Thank you for clarification. We did not realize system_app_data_file is mlstrustedobject. We will make some adjustment accordingly. > * Any world readable data in managed Profile from non-system > App can be accessed by system app if policy allows(Perhaps > this case may not be often). > 2. System App in Managed Profile if not categorized > * Doesn't need to define system app as mlstrustedsubject > * System App world readable data in the managed Profile *can > be accessed*by the non_system app outside of the managed > profile > * Any world readable data in managed Profile from non-system > App cannot be access by system app, Even both inside managed > profile. This may break apps. (Perhaps this case may not be > often). > > > > Looks like option 1 not only more secure but also more stable than > option 2. > > > > Your comments are welcome.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
