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.
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:
- 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?
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
