On Wed, 2017-01-25 at 00:26 +0000, Renuka Srinivasan wrote:
> I was looking into a denial involving dir search and found that in
> android N latest AOSP release, there are 2 mls contsraints related to
> dir search and they have different constraints. Please help me
> understand which is I am reading the file incorrectly. What are the
> conditions under which each one is used?
>
>
>
> 63# Constraints for app data files only.
> 64#
> 65
> 66# Only constrain open, not read/write.
> 67# Also constrain other forms of manipulation, e.g. chmod/chown,
> unlink, rename, etc.
> 68# Subject must be equivalent to object unless the subject is
> trusted.
> 69mlsconstrain dir { open search setattr rename add_name remove_name
> reparent rmdir }
> 70 (t2 != app_data_file or l1 eq l2 or t1 ==
> mlstrustedsubject);
> 71mlsconstrain { file lnk_file sock_file } { open setattr unlink link
> rename }
> 72 (t2 != app_data_file or l1 eq l2 or t1 ==
> mlstrustedsubject);
> 73
> 74#
> 75# Constraints for file types other than app data files.
> 76#
> 77
> 78# Read operations: Subject must dominate object unless the subject
> 79# or the object is trusted.
> 80mlsconstrain dir { read getattr search }
> 81 (t2 == app_data_file or l1 dom l2 or t1 ==
> mlstrustedsubject or t2 == mlstrustedobject);
Constraints for directories and for non-device files are split into two
cases, as noted in the comments: a constraint on access to app data
files (or to be more precise, to app_data_file), and a constraint on
access to any other file type.
In the app data file case, seapp_contexts enables per-user category
sets via levelFrom=user, and the restriction we want to enforce is that
an app can only open files created by apps running on behalf of the
same user (in the multi-user sense, not necessarily the same Linux
uid), but is allowed to read or write files created by apps running on
behalf of other users if the open file descriptors are received over
Binder or local socket IPC (i.e. no direct open of another user's
files, but can still share through system_server or other middleware
mechanisms).
For other files (e.g. general files under /data outside of app data
directories), categories are not being assigned and we just want the
conventional MLS rules (no-read-up, no-write-down), which in practice
means that the files will be generally readable (since they will be at
the lowest level, s0) and will only be writable by apps if marked as
mlstrustedobject.
Perhaps counter-intuitively, the constraints on app data files are
written as "(t2 != app_data_file or ..." because we want the constraint
to evaluate to true if the object/target type (t2) is not an app data
file OR if it meets the rest of the constraint, and vice versa for the
constraints on other files. Each constraint must evaluate to true in
order for the constrained permission to be allowed, so the individual
constraints on any given permission are ANDed together. The
constraints also differ due to the open vs read/write distinction made
for app data files (to allow sharing through Binder or local socket
IPC) vs. other files.
And of course, all files are still controlled by TE, so they are only
readable and/or writable if access is allowed to the corresponding type
in the first place; the MLS constraints merely further restrict access.
Hope that's clear; feel free to ask questions if not.
One question I have with respect to the constraints in N (and later) is
whether we ought to be applying the constraints on app data files to
more than just the app_data_file type, since N and later also apply
levelFrom=user to additional types in seapp_contexts. If so, then we
likely ought to define an attribute in the policy for all types that
should be restricted in this way, and use that attribute in the
constraint rather than writing it on individual types.
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
