That helps a lot Stephen! Thanks for the explanation! Regards Renuka
-----Original Message----- From: Stephen Smalley [mailto:s...@tycho.nsa.gov] Sent: Wednesday, January 25, 2017 6:08 AM To: Renuka Srinivasan; seandroid-list@tycho.nsa.gov Subject: Re: dir search mls rule 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.
