[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: Where do policies come from?
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2015-03-26 16:52:34
Message-ID: 55143952.10907 () tycho ! nsa ! gov
[Download RAW message or body]

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
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]