Hi Stephen, Actually what I described here is exact what you said in the link:
http://marc.info/?l=seandroid-list&m=141150669811670&w=2. - 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. Thank you for above comments. Here is my implementation below: Using isOwener attribute in seapp_contexts fileto make: Owner user: system_app and system_app_data_file have no category labeled. which is: User=system isOwner=true seinfo=platform domain=system_app type= system_app_data_file Secondary user: system_app, and system_app_data_file have category labeled, which is: User=system isOwner=false seinfo=platform domain=system_app type= system_app_data_file levelFrom=user We also define system_app is mlstrustedsubject and system_app_data_file is already mlstrustedobject. Therefore it is exact what you said in the above link. We have already used this approach in the actual testing. It works perfect. Please let me know if you any additional concerns. Regards, Jinlin From: William Roberts [mailto:[email protected]] Sent: Tuesday, September 08, 2015 12:33 PM To: Jinlin Xu Cc: Stephen Smalley; [email protected]; Dingbang Xu Subject: Re: possible approach for levelFrom=user On Tue, Sep 8, 2015 at 11:54 AM, Jinlin Xu <[email protected]<mailto:[email protected]>> wrote: > 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. It shouldn't, unless I misunderstand. The neverallows in seapp_contexts should just prevent assigning system_app to users other than system, but it should not prevent you from assigning a domain other than system_app to system UID apps (for the isOwner=false case, or for specific apps identified by seinfo and/or name). It would actually be useful to move non-owner system UID apps out of system_app because they have no reason to be able to write to /data/system, /data/misc/keychain, /data/misc/user, etc or to set system properties (DAC will already prevent them from doing so because they will run in a UID that has the non-zero user ID embedded in it, so their Linux UID will no longer match the system UID). Yes this neverallow just makes sure that only system uid is in system_app and only system_uid domains are assigned to system_app_data_file. One can run a system uid application in a different domain and app data folder context if they choose to do so. # system domains should never be assigned outside of system uid neverallow user=((?!system).)* domain=system_app neverallow user=((?!system).)* type=system_app_data_file <Jinlin> One situation we consider is: if we change a system app to other domain, for example abc_app domain in a deep customized environment. Neverallow rules may prevent abc_app domain to do something that system app can do, but other apps cannot do. > “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. DAC should prevent this already, because e.g. u1_system is not the same Linux UID as system (aka u0_system). The files would have to be world-accessible for this to happen. <Jinlin> world-accessible files is one of our isolation consideration. > “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. It is currently, but that could be changed as noted above. That would probably be a good idea regardless. _______________________________________________ Seandroid-list mailing list [email protected]<mailto:[email protected]> To unsubscribe, send email to [email protected]<mailto:[email protected]>. To get help, send an email containing "help" to [email protected]<mailto:[email protected]>. -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
