Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA <at> public.gmane.org>
Subject: Re: Mainstreaming SE Android
Newsgroups: gmane.comp.security.seandroid
Date: Tuesday 9th April 2013 12:51:37 UTC (over 4 years ago)
On 04/08/2013 03:57 PM, James Puderer wrote:
> I'm just getting started with SE Android.  So far, I really like the
> approach.   You guys have done some really great work!
>
> I'm very curious to know if there has been any indication from Google as
to
> if, when, and how SE Android might be mainstreamed into AOSP?
>
> I'm also wondering if the goal of mainstreaming SE Android is to define a
> "blessed" base policy that gets enforced by default on all Android
devices,
> or if it is expected that this would largely remain up to the device OEMs
> (so long as the devices pass CTS).

As Bill noted, most of SE Android has in fact been merged into AOSP 
(this has been an ongoing process over nearly the past year and a half). 
  The last few changes required for a functional SE Android system were 
merged recently.  You can build the AOSP master branch and just drop in 
a SELinux-enabled kernel, and you should have a basic working SE Android 
system.  You still need to put it into enforcing mode, which under AOSP 
you can only do temporarily via an adb shell su 0 setenforce 1 or 
permanently by putting setenforce 1 into the init.rc file (make sure the 
device boots and operates without denials first, as per the wiki).

What is missing from AOSP is:
1) The device admin support, and therefore the ability to support the 
SEAndroidAdmin app.  This has been rejected by AOSP due to concerns 
about the potential impact on compatibility.

2) Any of the middleware MAC mechanisms, including install-time MAC, 
except for a restricted form of its seinfo support for labeling apps.
In particular, the requirement by AOSP was that all third party apps 
must be treated alike.  Distinctions can only be made between system 
apps and third party apps and among the system apps, not between two 
different third party apps.

With regard to your latter question, our goal was to provide a default 
policy suitable for all Android devices (and at least a starting point 
for such a policy was released as part of SE Android and is now included 
in AOSP), but still provide flexibility to others, including the OEMs, 
MDMs, and ultimately the government or corporate enterprise, to 
customize policy for specific usage models, environments, and security 
requirements.  However, it appears that such flexibility won't be 
extended to MDMs or end users.  I expect OEMs will try to stay as close 
as possible to the default policy but will adjust it slightly as needed 
for their specific Android customizations and the particular integration 
for a specific device.






--
This message was distributed to subscribers of the seandroid-list mailing
list.
If you no longer wish to subscribe, send mail to
[email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
 
CD: 3ms