On Tue, Sep 23, 2014 at 2:06 PM, Stephen Smalley <[email protected]> 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. >> >> I could try to write this up, but I am not even 100% sure I understand >> what your doing here: >> >> switch (cur->levelFrom) { >> case LEVELFROM_APP: >> snprintf(level, sizeof level, "%s:c%u,c%u", >> context_range_get(ctx), appid & >> 0xff, >> 256 + (appid>>8 & 0xff)); >> break; >> case LEVELFROM_USER: >> snprintf(level, sizeof level, "%s:c%u,c%u", >> context_range_get(ctx), >> 512 + (userid & 0xff), >> 768 + (userid>>8 & 0xff)); >> break; >> case LEVELFROM_ALL: >> snprintf(level, sizeof level, >> "%s:c%u,c%u,c%u,c%u", >> context_range_get(ctx), appid & >> 0xff, >> 256 + (appid>>8 & 0xff), >> 512 + (userid & 0xff), >> 768 + (userid>>8 & 0xff)); >> break; >> default: >> goto err; >> >> >> >> 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.
I think that describes at a high level whats going on. > > 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). Yes and this is what I was trying to convey, you need both categories to be unique. Categories are sets and the definiition of a set is that their cannot be duplicate elements. > > 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. I think its the implementation detail I would like to see. Reading through the code magic masks and numbers appear, which I am not a fan of without comments. Why 512, why 768, why only the first two bytes of the uid, etc? I would imagine these would be the questions a new-comer would ask when looking through the code. Im just looking for something so future generations know what happened here, probably a block comment would suffice. > > 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: > > - We could leave them at s0 (i.e. no levelFrom=user) but mark their > domains as mlstrustedsubjects and possibly their data files as > mlstrustedobjects so that they can freely interact with both system > processes/resources at s0 and with apps running on behalf of any user. > However, this would mean that any one of these apps could bridge the > user boundary, whether the app was running on behalf of the owner or a > secondary user. > > - 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. > > - We could differentiate the handling of the owner instance of these > apps from secondary user instances using the new isOwner= input selector > that I recently added based on an earlier discussion on the list, > https://android-review.googlesource.com/#/c/107393/ > https://android-review.googlesource.com/#/c/107553/ > > We could use this to either only enable levelFrom=user on the secondary > instances, leaving the primary/owner instances at s0, as the secondary > instances cannot directly write to /data files outside their /data/data > directories or connect to limited-access services already due to DAC > (they run in a UID derived from both the user ID and the app ID, which > no longer matches the platform UID at the kernel level). Or we could > use it to run the primary instance and secondary instances in different > domains, thereby allowing us to make the primary instance a > mlstrustedsubject without doing the same for secondary instances. > > Thoughts? I haven't done any rigourous MLS testing with these attributes on Android handsets, so as far as compatability issues are concerned, I really can't make intelligent comments on that. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
