On 06/19/2014 01:17 PM, Sloan, John [GCS] wrote: > How interoperable (if at all) are persistent removable file systems > which may have been labeled with an updated file_contexts (and hence a > slightly different sepolicy)? > > > > For example, if I label DISK2 on SYSTEM2 that has a slighted updated > file_contexts/sepolicy, can I mount DISK2 on SYSTEM1 that has an older > policy? In my particular case, DISK2 would _/not/_ contain any types > that were not defined on SYSTEM1, but the policy on SYSTEM2 might > contain additional types that do not appear on DISK2. > > > > Real-life example: moving DISK2 from the development system (SYSTEM2) > for which a new policy might be under development to a production system > (SYSTEM1) still using the older policy. I’m wondering if we must > completely relabel DISK2 on SYSTEM1 before we can safely use it. > > > > I’m mostly worried that SELinux binary artifacts (if such exists) in the > extended attributes might have a different mapping from the same > symbolic names between SYSTEM1 and SYSTEM2. I’ve been using tools like > sediff and seinfo to try to answer this question but with no luck. I > also haven’t had any luck trying to extract the actual extended > attributes on the file systems to compare them, but that is probably > pilot error on my part somehow. > > > > If the file type in the extended attributes is generated using a hash > from the symbolic name, or is actually the symbolic name itself, I’m not > concerned. If it’s generated using some simper approach, I’ll probably > have to come up with a Plan B.
The only thing stored in the security.selinux attribute on the filesystem is the string representation of the security context, e.g. u:object_r:system_data_file:s0. Exactly what you see when you run ls -Z or call getfilecon(). So if you mount it on SYSTEM1, then as long as SYSTEM1's policy recognizes that security context string as valid (e.g. type is defined), you won't have any issue. If the security context is not recognized as valid, then the kernel will treat the file as if it had the unlabeled context, in which case only domains allowed to access unlabeled files will be able to access it. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
