On 9/23/2014 5:06 PM, Stephen Smalley wrote: > On 09/23/2014 12:49 PM, William Roberts wrote: >> Now that levelFrom=user is finally officially into mainline. It might >> make sense to finally document what they do a bit more thoroughly, >> especially the code in android.c, its not obvious. [cut]
>> Are you just ensuring that each category is unique so their are no >> duplicates? if the two bytes were both 0x4, you don't want s0:c4,c4, >> instead you would get s0:c516,c772. Thats my understanding, but it may >> be wrong. > > For those who may not have seen the change in AOSP, it is here: > https://android-review.googlesource.com/#/c/107443/ > > I think the change description is at least a good start at documenting > the effect of enabling levelFrom=user, although it doesn't delve into > this kind of implementation detail. > > The category set is a set (internally a bitmap), so s0:c4,c4 is > identical to s0:c4 (try setting the former on a process or file and then > looking at what the kernel reports in ps -Z or ls -Z output - it will be > the latter). > > We want the category set to be unique on whatever granularity we have > selected by the levelFrom= specifier (per-app, per-user, or > per-combination) so that the levels will never be the same for different > apps, users, or combination thereof. By encoding each ID as a category > pair, we can represent up to 2^16 app IDs and up to 2^16 user IDs > within the 1024 categories defined in policy, including for the > levelFrom=all or any kind of mixed usage of levelFrom=app and > levelFrom=user without concern. > > There are some aspects of the levelFrom=user support that may yet need > to be changed. I am undecided on how the apps that run in one of the > predefined platform UIDs (e.g. system, nfc, bluetooth, ...) should be > handled. I did not enable levelFrom=user on their seapp_contexts > entries, so they all presently run at s0 even if they are separately > instantiated per user. This seemed to work better by default, as these > apps directly write to files outside of their /data/data directories and > directly connect to system services not accessible to regular apps, so > putting them into the same level (s0) as these system processes and > services seemed to produce less friction. However, this may break > interactions between these apps and regular apps, even when running on > behalf of the same user, due to the difference in levels. We have > several options if this proves to be problematic: [cut] > - We could enable levelFrom=user for these apps 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. If the interactions break as you describe above, this seems like the best solution. It makes more sense for the system domains to be trusted, rather than this subset of apps being trusted, since app separation is the purpose of MLS here. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
