> 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). <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].
