On Tue, Sep 8, 2015 at 11:54 AM, Jinlin Xu <[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] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [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].
