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.
