On 03/26/2015 11:47 AM, Daniel Song wrote: > Hello all, > > I just started looking at SEAndroid and have a question about SEAndroid > policies. How are the policies made? I see that lots of changes are > being made to the policies > (https://android-review.googlesource.com/#/q/project:platform/external/sepolicy) > but how are these policies being made? What is the intuition behind > these changes? Do you run any static analysis to see which processes > needs to be allowed communicate? > > Also, I read the paper "Security Enhanced Android: Bringing Flexible MAC > to Android" and it states that the policies are made from scratch. Does > it mean SEAndroid used none of the SELinux policies? I suspect since > Android is built on the linux kernel so there must be some policies that > comes from SELinux policies.
To answer your last question first, yes, it means that SE (for) Android did not use anything from the SELinux reference policy. We explained why in the paper; see section 2.3. About the only thing in common between Linux distributions and Android is the kernel, and the policy is a specification of what userspace can do, so there is nothing in common other than the kernel definitions of classes and permissions. The original policy was designed as described in section 3.3 of the paper. It was initially set up based on the security goals we described in the paper and an understanding of Android's architecture and usage model, and then refined through testing. Since the time of the paper, policy has changed significantly, both as a result of much wider testing and as a result of tackling additional specific security goals. Many of those goals are described in the talk I gave at LSS 2014, http://kernsec.org/files/lss2014/lss2014_androidtcb_smalley.pdf and are embodied in the Android 5.0 Lollipop release (which came after that talk and therefore is only referred to as the L release in the slides since the number and name was not yet known). Many of the security goals are also checked at policy build time using neverallow rules in the policy, and as part of Android compatibility testing via the SELinux CTS tests, http://seandroid.bitbucket.org/RunningtheCTS.html Ongoing changes to policy in AOSP master generally reflect one or more of: 1. Fixing breakage caused by SELinux denials discovered through testing or user feedback, i.e. allowing actions that are legitimate, 2. Adjusting the policy to fit changing code changes to AOSP that alter the permission requirements, either to allow an action required by the new code or to reduce permissions that are no longer needed by the code for least privilege, 3. Hardening the policy to provide better protection or least privilege, typically with a particular threat or security goal in mind, 4. Adding new neverallow rules to policy to validate that additional security properties are guaranteed for all future policies, including even device-specific policies (which live under each device/<vendor>/<board>/sepolicy subdirectory and are unioned into the external/sepolicy at build time). _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
