Difference between revisions of "SEforAndroid"

From SELinux Wiki
Jump to: navigation, search
(Building for a Device)
(152 intermediate revisions by the same user not shown)
Line 1: Line 1:
== What is SE for Android? ==
+
Security Enhancements (SE) for Android™ was a NSA-led project that created and released an open source reference implementation of how to enable and apply SELinux to Android, made the case for adopting SELinux into mainline Android, and worked with the Android Open Source Project (AOSP) to integrate
 +
the changes into mainline Android. As a result, SELinux is now a core part of Android.
 +
See https://source.android.com/security/selinux/ for further information on SELinux in Android.
  
Security Enhancements for Android™ (SE for Android) is a project to identify and address critical gaps in the security of Android. Initially, the project is enabling the use of SELinux in Android in order to limit the damage that can be done by flawed or malicious apps and in order to enforce separation guarantees between apps. However, the scope of the project is not limited to SELinux.
+
SE for Android was originally called Security Enhanced Android (SE Android) but was renamed to comply with the Android brand guidelines.
 +
Hence, you will see the older name in many of the presentations and papers below.
  
SE for Android also refers to the reference implementation produced by the project.  The current reference implementation provides a worked example of how to enable and apply SELinux at the lower layers of the Android software stack and provides a working demonstration of the value provided by SELinux in confining various root exploits and application vulnerabilities.
+
SE for Android used to maintain its own source code repositories on bitbucket.org but these have been removed since the code has all been merged to AOSP.
 
+
== Merge Status ==
+
 
+
Android 4.3 was the first Android release version to fully include and enable the SELinux support contributed by the SE for Android project.  Android 4.4 is the first release to put SELinux into enforcing mode, beginning by confining a specific set of root daemons.
+
 
+
The Android SELinux support is discussed in https://source.android.com/devices/tech/security/se-linux.html.
+
 
+
Prior versions such as Android 4.2 included a subset of the SELinux support but not a complete, functional set, and the code was
+
disabled by default in the build (wrapped with HAVE_SELINUX conditionals).
+
 
+
You can build mainline Android 4.3 or 4.4 and drop in a SELinux-enabled kernel without requiring further changes if you only want the core SELinux functionality.  Under 4.3, you will still need to put the device into enforcing mode, which you can 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 [[#Getting_Started | Getting Started]]). Under 4.4, the system starts in global enforcing mode although many domains are in per-domain permissive mode by default.
+
 
+
What is missing from mainline Android presently is:
+
* The new device admin APIs for managing the SELinux functionality and the SEAdmin sample device admin app for using those APIs.
+
 
+
* Any of the [[#Middleware_MAC | middleware MAC]] mechanisms, including install-time MAC, except for a restricted form of its seinfo support for labeling apps.
+
 
+
* The audit daemon (auditd) for collecting SELinux audit denials and writing them to /data/misc/audit/audit.log.
+
 
+
* Our sample policy configuration (Android 4.3 shipped with a policy that was fully permissive and unconfined, while Android 4.4 begins to apply enforcing mode to a specific set of domains).
+
 
+
* Some improvements to how policy reloading is handled, particularly avoiding the need to restart daemons.
+
 
+
* Proper security labeling of multi-user data directories.
+
 
+
If you want this additional functionality or our sample policy configuration, you will still need to download and use our modified projects as described below.
+
 
+
== Papers and Presentations ==
+
  
 +
Presentations and papers describing SE for Android included:
 
* The Case for SE Android, Linux Security Summit 2011, Sep 2011. [http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf Slides]
 
* The Case for SE Android, Linux Security Summit 2011, Sep 2011. [http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf Slides]
* The Case for Security Enhanced (SE) Android, Android Builders Summit 2012, Feb 2012. [https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_smalley.pdf Slides] [http://video.linux.com/videos/the-case-for-security-enhanced-se-android Video]
+
* The Case for Security Enhanced (SE) Android, Android Builders Summit 2012, Feb 2012. [https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_smalley.pdf Slides]
* Security Enhanced (SE) Android, 16th Semi-Annual Software Assurance Forum, Mar 2012. [https://buildsecurityin.us-cert.gov/swa/presentations_032612/SE%20Android%20(Panel%20on%20Securing%20Mobile%20Operatins%20Systems)%20-%20Stephen%20Smalley.pdf Slides]
+
 
* Security Enhanced (SE) Android, LinuxCon North America 2012, Aug 2012.  [https://events.linuxfoundation.org/images/stories/pdf/lcna_co2012_smalley.pdf Slides]
 
* Security Enhanced (SE) Android, LinuxCon North America 2012, Aug 2012.  [https://events.linuxfoundation.org/images/stories/pdf/lcna_co2012_smalley.pdf Slides]
 
* Middleware MAC for Android, Linux Security Summit 2012, Aug 2012.  [http://kernsec.org/files/LSS2012-MiddlewareMAC.pdf Slides]
 
* Middleware MAC for Android, Linux Security Summit 2012, Aug 2012.  [http://kernsec.org/files/LSS2012-MiddlewareMAC.pdf Slides]
* Security Enhanced (SE) Android:  Bringing Flexible MAC to Android, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013.  [http://www.internetsociety.org/sites/default/files/02_4.pdf Paper] [http://www.internetsociety.org/sites/default/files/Presentation02_4.pdf Slides]
+
* Security Enhanced (SE) Android:  Bringing Flexible MAC to Android, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013.  [https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/security-enhanced-se-android-bringing-flexible-mac-android Paper and Slides]
*  Laying a Secure Foundation for Mobile Devices, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013. [http://www.internetsociety.org/sites/default/files/Presentation_Smalley.pdf Slides]
+
*  Laying a Secure Foundation for Mobile Devices, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013. [https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/laying-secure-foundation-mobile-devices/ Slides]
* Laying a Secure Foundation for Mobile Devices, International Council on Systems Engineering (INCOSE) Chesapeake Chapter Monthly Meeting, Aug 2013. [http://www.incose-cc.org/http://www.incose-cc.org/images/LayingASecureFoundation-Smalley-2013-08.pdf Slides]
+
* Security Enhancements (SE) for Android, Android Builders Summit 2014, Apr 2014. [http://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf Slides]
 
+
* Protecting the Android TCB with SELinux, Linux Security Summit 2014, Aug 2014. [http://kernsec.org/files/lss2014/lss2014_androidtcb_smalley.pdf Slides]
== How do I get the code? ==
+
* SELinux in Android Lollipop and Marshmallow, Linux Security Summit 2015, Aug 2015. [http://kernsec.org/files/lss2015/lss2015_selinuxinandroidlollipopandm_smalley.pdf Slides]
 
+
First, you should make sure that you are able to successfully download, build and run the Android Open Source Project (AOSP) source code by following the instructions starting from
+
http://source.android.com/source/initializing.html.
+
 
+
The AOSP instructions are for Ubuntu or MacOS X users; we are building on
+
64-bit Fedora.
+
Some Fedora-specific notes can be found further below.  Ubuntu or MacOS X should also work as build hosts;
+
see the AOSP instructions for specific information about building AOSP on those operating systems.
+
 
+
General questions about building and running Android should be directed to the android-building discussion group.  Only questions specific to SE for Android should be directed to the seandroid-list mailing list.
+
 
+
=== Using the master branch ===
+
 
+
SE for Android development is done relative to the master branch of AOSP, with our changes on a
+
seandroid branch.  If you want to work with the latest SE for Android code, you should clone the master
+
branch of AOSP as your starting point.
+
 
+
Once you have successfully built and run AOSP, you can obtain a local_manifest.xml file specifying the SE for Android git trees from
+
https://bitbucket.org/seandroid/manifests.
+
Copy this file to the .repo subdirectory of your AOSP clone, and
+
then run repo sync.  Your tree should now include the SE for Android modifications.
+
 
+
The git projects can be accessed using https or ssh.  Cloning via https can sometimes fail, particularly for large repos.
+
Cloning via ssh requires that you first set up an account on bitbucket.org and upload a public key.
+
 
+
An abbreviated example sequence of commands is shown below for downloading the AOSP master branch with
+
the SE for Android modifications using https-based access.
+
<pre>
+
git clone https://bitbucket.org/seandroid/manifests.git
+
mkdir seandroid
+
cd seandroid
+
repo init -u https://android.googlesource.com/platform/manifest
+
repo sync
+
cp ../manifests/local_manifest.xml .repo
+
repo sync
+
</pre>
+
 
+
If you have set up an account on bitbucket.org and uploaded a ssh public key, you can use the ssh-based local manifest instead,
+
as shown below.
+
<pre>
+
git clone -b master-ssh git@bitbucket.org:seandroid/manifests.git
+
mkdir seandroid
+
cd seandroid
+
repo init -u https://android.googlesource.com/platform/manifest
+
repo sync
+
cp ../manifests/local_manifest.xml .repo
+
repo sync
+
</pre>
+
 
+
=== Using a release version ===
+
 
+
We have created branches of SE for Android relative to specific Android release versions.
+
The base version is the name of the AOSP release tag from which the branch was forked. If you want to use a stable release of Android as
+
your baseline, then you should clone the corresponding release tag of AOSP as your starting point.
+
 
+
{|
+
! align="left" | Base Version
+
! align="left" | SE Branch
+
! align="left" | Devices
+
|-
+
| android-4.4_r1
+
| seandroid-4.4
+
| hammerhead
+
|-
+
| android-4.3_r3
+
| seandroid-4.3_r3
+
| mako, maguro, manta (requires further binaries)
+
|-
+
| android-4.3_r2.3
+
| seandroid-4.3_r2
+
| flo
+
|-
+
| android-4.3_r1.1
+
| seandroid-4.3
+
| mako, grouper, maguro, manta (requires further binaries)
+
|-
+
| android-4.2.2_r1.2
+
| seandroid-4.2
+
| mako, grouper, maguro, manta
+
|-
+
| android-4.1.2_r2.1
+
| seandroid-4.1.2
+
| wingray, crespo, crespo4g
+
|}
+
 
+
Once you have successfully built and run the AOSP sources, you can obtain the version-specific local_manifest.xml file from
+
the corresponding seandroid-4.x branch of https://bitbucket.org/seandroid/manifests.
+
Copy this file to the .repo subdirectory of your AOSP clone, and
+
then run repo sync.  Your tree should now include the SE for Android modifications relative
+
to the released version.
+
 
+
An abbreviated example sequence of commands is shown below for downloading the android-4.4_r1 release with
+
the SE for Android modifications.
+
<pre>
+
git clone -b seandroid-4.4 https://bitbucket.org/seandroid/manifests.git
+
mkdir seandroid-4.4
+
cd seandroid-4.4
+
repo init -u https://android.googlesource.com/platform/manifest -b android-4.4_r1
+
repo sync
+
cp ../manifests/local_manifest.xml .repo/
+
repo sync
+
</pre>
+
 
+
If you want to use ssh-based access instead, have set up an account on bitbucket.org and have uploaded a ssh public key,
+
you can use the -ssh branch of the manifests project.
+
<pre>
+
git clone -b seandroid-4.4-ssh git@bitbucket.org:seandroid/manifests.git
+
mkdir seandroid-4.4
+
cd seandroid-4.4
+
repo init -u https://android.googlesource.com/platform/manifest -b android-4.4_r1
+
repo sync
+
cp ../manifests/local_manifest.xml .repo/
+
repo sync
+
</pre>
+
 
+
The same instructions can be applied for other versions such as 4.2 but we recommend using the latest version supported by your device.
+
 
+
== Git Trees and Branches ==
+
 
+
In addition to using repo to clone SE for Android, it is also possible to
+
directly clone the SE for Android git repos via git if you merely want to
+
examine the trees.  The trees can be cloned via:
+
<pre>
+
git clone https://bitbucket.org/seandroid/ + project path
+
</pre>
+
where the "+ project path" is replaced by the path to the specific git project
+
you wish to clone.
+
 
+
The manifests git project contains the local_manifest.xml files.  The master branch
+
contains a local_manifest.xml file referencing the seandroid branch relative to AOSP master,
+
while the seandroid-4.x branches contain a local_manifest.xml file referencing the seandroid-4.x branches
+
relative to specific AOSP releases.
+
 
+
Each kernel tree has a seandroid-<board>-<version> branch that was
+
forked from the existing android-<board>-<version> branch.  You can
+
extract individual patches from the kernel trees by running git
+
format-patch <remote-name>/android-<board>-<version>.  If you cloned via repo,
+
then the <remote-name> will be bitbucket; if you cloned directly via git clone, then
+
the <remote-name> will be origin.  Example for the Galaxy Nexus kernel:
+
<pre>
+
cd kernel/omap
+
git branch -r
+
git checkout bitbucket/seandroid-omap-tuna-3.0-jb-mr2
+
git format-patch bitbucket/android-omap-tuna-3.0-jb-mr2
+
</pre>
+
 
+
Each modified AOSP tree has a seandroid branch that was forked from
+
the master branch and a set of seandroid-x.y branches.  You can extract individual patches from the AOSP trees
+
by running git format-patch <remote-name>/master (for the seandroid branch) or
+
git format-patch <release-tag> (for the seandroid-x.y branches). 
+
Example for frameworks/base relative to the master branch,
+
assuming you cloned the seandroid branch:
+
<pre>
+
cd seandroid/frameworks/base
+
git format-patch bitbucket/master
+
</pre>
+
 
+
Example for frameworks/base relative to the 4.4 release,
+
assuming you cloned the seandroid-4.4 branch:
+
<pre>
+
cd seandroid-4.4/frameworks/base
+
git format-patch android-4.4_r1
+
</pre>
+
 
+
libsepol, checkpolicy, libselinux and sepolicy are new trees added for SE for Android.
+
libsepol and checkpolicy are a port of the SELinux policy compiler, modified slightly
+
to build as part of Android and to build on MacOS X.  These two components are only built
+
for the build host and are not installed to the device. libselinux is a port of a subset of the upstream libselinux to Android plus some new Android-specific interfaces, while sepolicy is a completely new SELinux policy written from scratch for Android. libselinux is built for both the build host (for use by certain build tools) and for the device.  sepolicy is built once; the binary policy format is architecture-independent.
+
 
+
== Fedora-Specific Notes ==
+
 
+
AOSP only officially supports building on specific versions of Ubuntu and MacOS X.
+
We have been building on Fedora in addition to Ubuntu and MacOS X. This section contains some tips for building
+
on Fedora if you wish to do so. We have successfully built on 64-bit Fedora.  Beyond a typical install, we typically have
+
to install the following to build AOSP.  The precise package list may
+
vary for different versions of Fedora.
+
<pre>
+
yum groupinstall "Development Tools" "Development Libraries"
+
yum install gperf perl-Switch
+
yum install glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686 readline-devel.i686 mesa-libGL-devel.i686
+
</pre>
+
 
+
AOSP only officially supports the Oracle/Sun JDK, not OpenJDK.  Improved
+
support for OpenJDK has been going into the master branch, but it is
+
unclear as to whether it yields a working result.  We are presently
+
building with the Sun JDK.  Obtain the Oracle/Sun JDK, install it, and remove
+
OpenJDK or make sure the Oracle/Sun JDK location comes first in your PATH.
+
 
+
You may need to patch the LOCAL_LDLIBS definitions of some makefiles
+
to include all library dependencies.  We had to add LOCAL_LDLIBS += -lX11
+
to development/tools/emulator/opengl/host/renderer/Android.mk.
+
 
+
You will need to add udev rules under /etc/udev/rules.d if you want to
+
be able to access a device via adb without being root.  For example:
+
<pre>
+
$ cat /etc/udev/rules.d/51-android.rules
+
ATTR{idVendor}=="18d1", MODE="0666"
+
ATTR{idVendor}=="22b8", MODE="0666"
+
ATTR{idVendor}=="04e8", MODE="0666"
+
</pre>
+
 
+
You can get adb, fastboot, etc in your path by running the
+
following:
+
<pre>
+
export PREFIX=/path/to/your/aospclone
+
cd $PREFIX
+
source build/envsetup.sh
+
setpaths
+
</pre>
+
 
+
If you have run lunch in the same shell in order to build AOSP,
+
then your path is already set correctly.
+
 
+
== Building for the Emulator ==
+
 
+
In order to run SE for Android on the Android emulator, you need a
+
kernel with the necessary support for SELinux.  On 4.4 or the current AOSP master
+
branch, the prebuilt emulator kernel (under prebuilts/qemu-kernel) already includes the SELinux support
+
and the emulator build has been switched to use ext4 images rather than yaffs2 images, thereby
+
removing the need for our patches to yaffs2 to support file security labeling.  On 4.3 or earlier,
+
you must build a kernel from source with the SELinux support enabled in the kernel configuration.
+
The emulator kernel source code is located under kernel/goldfish.
+
<pre>
+
export PREFIX=/path/to/your/aospclone
+
cd $PREFIX/kernel/goldfish
+
make ARCH=arm goldfish_armv7_defconfig
+
make ARCH=arm CROSS_COMPILE=$PREFIX/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-
+
</pre>
+
 
+
On MacOS X, you need to specify the darwin-x86 compiler toolchain instead of the linux-x86 toolchain:
+
<pre>
+
make ARCH=arm CROSS_COMPILE=$PREFIX/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6/bin/arm-eabi-
+
</pre>
+
and you must follow the steps described in:
+
http://code.google.com/p/android/issues/detail?id=2755
+
 
+
You can build the Android userspace in the usual manner, except that if
+
building a version prior to 4.3, you must specify HAVE_SELINUX=true on the make command line or set it in your environment prior to running make:
+
<pre>
+
cd $PREFIX
+
source build/envsetup.sh
+
lunch full-eng
+
export HAVE_SELINUX=true
+
make
+
</pre>
+
 
+
(It is no longer necessary to set HAVE_SELINUX=true for 4.3 or later builds, but it remains true for 4.2.)
+
 
+
If you are running a release version rather than master, you must run the emulator with the kernel you built above:
+
<pre>
+
emulator -show-kernel -kernel kernel/goldfish/arch/arm/boot/zImage
+
</pre>
+
 
+
The above command presumes that you previously ran lunch (as during a
+
build) or manually set your ANDROID_PRODUCT_OUT and PATH variables
+
appropriately.
+
 
+
== Building for the x86-based Emulator ==
+
 
+
Building for the Android x86 emulator is similar to the above instructions, but using
+
the x86 goldfish_defconfig as the kernel configuration and the
+
full_x86-eng userspace build target.
+
To build the kernel, you can do the following:
+
<pre>
+
export PREFIX=/path/to/your/aospclone
+
cd $PREFIX/kernel/goldfish
+
../../external/qemu/distrib/build-kernel.sh --arch=x86
+
</pre>
+
 
+
You can build the Android userspace for x86 as follows:
+
<pre>
+
cd $PREFIX
+
source build/envsetup.sh
+
lunch full_x86-eng
+
export HAVE_SELINUX=true
+
make
+
</pre>
+
 
+
You must run the emulator with the kernel you built:
+
<pre>
+
emulator -show-kernel -kernel kernel/goldfish/arch/x86/boot/bzImage
+
</pre>
+
 
+
The above command presumes that you previously ran lunch (as during a
+
build) or manually set your ANDROID_PRODUCT_OUT and PATH variables
+
appropriately.
+
 
+
== Building for a Device ==
+
 
+
It is advisable to make a backup of your device prior to trying to
+
install AOSP on it, typically using a recovery ROM such as
+
ClockworkMod.  Also note that you will erase your user data when you
+
unlock the bootloader.  Finally, keep in mind that AOSP does not
+
include various proprietary apps such as the Google apps so you will
+
not have them in your build unless you extract a copy from your device
+
and re-package them for your build.
+
 
+
As in the emulator case, you will need a kernel with
+
the necessary support for SELinux.  On 4.3 or later, the
+
prebuilt kernels include SELinux support so you do not need to build your own kernel;
+
for older versions such as 4.2 you must build your own kernel.  However, even on 4.3 or later,
+
you may still wish to build your own kernel to enable
+
more complete auditing support (in particular pathname collection for syscall audit) and other features
+
that are only presently in our kernel trees.
+
 
+
Various kernel source trees are available under the kernel/ directory.  Use the right kernel tree, branch and
+
configuration for your device.  For example, to build
+
for the Galaxy Nexus phone, you would do the following:
+
<pre>
+
export PREFIX=/path/to/your/aospclone
+
cd $PREFIX/kernel/omap
+
make ARCH=arm tuna_defconfig
+
make ARCH=arm CROSS_COMPILE=$PREFIX/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-
+
</pre>
+
 
+
On MacOS X, you need to specify the darwin-x86 compiler toolchain instead of the linux-x86 toolchain:
+
<pre>
+
make ARCH=arm CROSS_COMPILE=$PREFIX/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6/bin/arm-eabi-
+
</pre>
+
 
+
General AOSP instructions for building kernels can be found at:
+
http://source.android.com/source/building-kernels.html.
+
However, those instructions are for rebuilding the kernel that matches the AOSP prebuilt kernel;
+
you will need to instead use our branches or port our modifications over to the kernel you are using.
+
The correct kernel project, branch, and config to use for each device is shown below.  Note that
+
there may be multiple branches in the same kernel project for different Android versions (e.g. samsung) or different
+
devices (e.g. omap, tegra).  Older branches may also exist for earlier Android releases.
+
 
+
{|
+
! align="left" | Version
+
! align="left" | Device
+
! align="left" | Project
+
! align="left" | Branch
+
! align="left" | Config
+
! align="left" | Notes
+
|-
+
| 4.3.1_r1
+
| Nexus 7 2013 LTE (deb/razorg)
+
| kernel/msm
+
| seandroid-msm-flo-3.4-jb-mr2
+
| flo_defconfig
+
| Untested
+
|-
+
| 4.3_r2.3
+
| Nexus 7 2013 (flo/razor)
+
| kernel/msm
+
| seandroid-msm-flo-3.4-jb-mr2
+
| flo_defconfig
+
| Untested
+
|-
+
| 4.3_r3
+
| Nexus 10 (manta)
+
| kernel/exynos
+
| seandroid-exynos-manta-3.4-jb-mr2
+
| manta_defconfig
+
| See https://groups.google.com/forum/#!topic/android-building/OvPkVsjp63Y
+
|-
+
| 4.3_r3
+
| Nexus 4 (mako)
+
| kernel/msm
+
| seandroid-msm-mako-3.4-jb-mr2
+
| mako_defconfig
+
|
+
|-
+
| 4.3_r1.1
+
| Nexus 7 (grouper)
+
| kernel/tegra
+
| seandroid-tegra3-grouper-3.1-jb-mr2
+
| tegra3_android_defconfig
+
|
+
|-
+
| 4.3_r3
+
| Galaxy Nexus (maguro)
+
| kernel/omap
+
| seandroid-omap-tuna-3.0-jb-mr2
+
| tuna_defconfig
+
|
+
|}
+
 
+
For the device, you need your modified kernel to be included in the
+
boot partition image (boot.img) rather than the prebuilt kernel.
+
You can do this by specifying TARGET_PREBUILT_KERNEL to refer to the location of your kernel.
+
You can alternatively unpack the boot image and repack it with your own
+
kernel after building AOSP.
+
 
+
Follow the AOSP instructions for building for your device
+
as per
+
http://source.android.com/source/building-devices.html
+
except that if building a version or branch before 4.3, you will need to specify HAVE_SELINUX=true on the make command line
+
or set it in your environment prior to running make, e.g.
+
<pre>
+
cd $PREFIX
+
source build/envsetup.sh
+
lunch full_maguro-userdebug
+
export HAVE_SELINUX=true
+
make
+
</pre>
+
 
+
(It is no longer necessary to set HAVE_SELINUX=true for 4.3 or later builds, but it remains true for 4.2.)
+
 
+
The above example uses the userdebug build variant.  For a production build, you should use a user build instead, e.g.
+
<pre>
+
lunch full_maguro-user
+
</pre> 
+
 
+
The build system signs packages with the testkeys provided in the source tree. Because the testkeys are part of the standard Android open source distribution, they should never be used for production devices. Instead, you should generate and use your own private keys for creating production builds.  The development/tools/make_key script can be used to generate keys; you can see how it was used to generate the test keys in the build/target/product/security/README file.  Note that if you generate your own keys for signing, you need to update the external/sepolicy/keys.conf configuration with the paths to the production keys.  This configuration is used to generate the final mac_permissions.xml configuration.  On 4.3 and master, the sign_target_files_apks script has been updated to automatically rewrite mac_permissions.xml with the new certificates.
+
 
+
== Getting Started ==
+
 
+
Once you have the emulator or a device running SE for Android, you can run adb shell and then look for signs that SELinux is present, e.g.
+
<pre>
+
getenforce
+
ls -Z
+
ps -Z
+
dmesg | grep SELinux
+
</pre>
+
 
+
The separate SEAdmin app allows you to view or change your enforcing status and policy booleans.
+
You must first activate it as a device admin, then activate it as a SELinux admin, and then
+
select the SELinux Admin to view or change the SELinux settings (and similarly for MMAC administration,
+
which deals with the middleware MAC mechanisms).
+
 
+
By default, on 4.3 and earlier versions, the system will be in permissive mode, i.e. it will log
+
SELinux denials but not enforce them.  Before putting it into enforcing
+
mode, make sure you don't have any residual denials to address in your
+
policy, e.g.
+
<pre>
+
adb shell su 0 dmesg | grep avc
+
</pre>
+
or, if running auditd,
+
<pre>
+
adb shell su 0 cat /data/misc/audit/audit.log | grep avc
+
</pre>
+
should show no output.
+
 
+
To set enforcing mode at runtime, you can run "setenforce 1"
+
from an adb root shell, e.g.:
+
<pre>
+
adb shell su 0 setenforce 1
+
</pre>
+
 
+
To cause the phone to always boot in enforcing mode,
+
add "setenforce 1" to one of the init.rc files, rebuild,
+
and reflash your boot image.  In Android 4.4, the
+
setting of enforcing mode is handled directly in the init program
+
code, and can be changed by changing the value of ro.boot.selinux.
+
 
+
Note that these commands only control the system-wide enforcing mode for SELinux;
+
even if you setenforce 1, specific domains may operate in permissive mode if their policy declares them as permissive domains
+
(look for "permissive" in the .te files or use seinfo --permissive on the binary sepolicy file).
+
 
+
Alternatively, you can use the SEAdmin app to set your enforcing status.
+
The enforcing status will be saved and restored by the system_server on each boot.
+
 
+
If not running auditd, you can capture policy denials for later use in policy debugging as follows:
+
<pre>
+
adb shell su 0 cat /proc/kmsg > dmesg.txt &
+
</pre>
+
 
+
If running auditd, the denials will be written instead to /data/misc/audit/audit.log on the device.
+
 
+
You can later apply standard SELinux tools such as audit2allow to these logs, as in:
+
<pre>
+
audit2allow -p out/target/product/<device>/root/sepolicy < dmesg.txt
+
</pre>
+
 
+
However, note that you must specify that you are using a policy other than the SELinux policy
+
active on the build host by using the -p option as shown above.
+
 
+
== Policy ==
+
 
+
The SE for Android policy sources are located under external/sepolicy.
+
The policy consists of source files used to generate the SELinux
+
kernel policy file, a file_contexts configuration, a
+
property_contexts configuration, a seapp_contexts configuration, and a mac_permissions.xml configuration.
+
The file_contexts configuration is used
+
to label files at build time (e.g. the system partition) and at
+
runtime (e.g. device nodes, service socket files, /data directories created
+
by init.rc, ...). The property_contexts configuration is used to specify
+
the security context of Android properties for permission checking purposes.
+
The seapp_contexts configuration is used to label app processes and app package directories. The mac_permissions.xml configuration is the middleware MAC policy.  The property_contexts, seapp_contexts, and mac_permissions.xml configurations are unique to SE for Android (i.e. they were not part of the regular SELinux policy).
+
 
+
Device-specific policy can be specified by defining BOARD_SEPOLICY_DIRS, BOARD_SEPOLICY_UNION and/or BOARD_SEPOLICY_REPLACE variables in a BoardConfig.mk file under the device/<vendor>/<device> or vendor/<vendor>/<device> directories.  An example can be found in device/samsung/tuna/BoardConfig.mk, which defines these variables to reference device-specific policy files under device/samsung/tuna/sepolicy.  Documentation for per-device policy can be found in external/sepolicy/README.
+
 
+
SELinux kernel policy is presently compiled as part of the Android build
+
and added to the ramdisk image so that it can be loaded by init very
+
early in boot, before mounting the system partition.  Once the data partition has been mounted, policy can
+
be updated by placing policy files under a subdirectory of /data/security, creating a symbolic link named current under
+
/data/security to that subdirectory, and setting the selinux.reload_policy property to 1 (setprop selinux.reload_policy 1).  This will trigger a reload of policy by init.  Note that for the kernel policy, you must recompile the sepolicy file (make sepolicy) on the build host and push that to the subdirectory of /data/security, not the source .te files.  If you want the policy to be loaded from /data/security automatically on each boot, add the setprop command to the post-fs-data section of the init.rc file (we have done this on our seandroid, seandroid-4.3, and seandroid-4.4 branches).
+
 
+
Historical note:  The location for updated policy files was originally the existing /data/system directory and then later moved to its own /data/security directory.  In 4.3, the code was further changed to look under /data/security/current, where current is expected to be a symlink to the actual location (typically a subdirectory of /data/security), in order to more easily support policy updates.  See below for an example of using this mechanism to load a policy with dontaudit rules removed.
+
 
+
== Policy Updates ==
+
 
+
Prior to Android 4.3, we developed a set of extensions to the Android device admin APIs for setting enforcing mode, policy booleans, and providing updated policy files to drop under the /data/security directory.  Those APIs are demonstrated by the SEAdmin app.  However, the APIs were not accepted into AOSP and are thus only available if you are using our code.
+
 
+
Android 4.3 extended the ConfigUpdate mechanism for handling various kinds of configuration updates to also support SELinux policy updates (via
+
the SELinuxPolicyInstallReceiver).  Using this mechanism requires creating a signed policy bundle that can be shipped to the device and then broadcasting an android.intent.action.UPDATE_SEPOLICY Intent on the device to trigger the SELinuxPolicyInstallReceiver to validate the bundle, unpack the policy files from it under /data/security/contexts (with a symbolic link created from /data/security/current), trigger a policy reload to load the new policy files, and then set a new persist.selinux.enforcing Android property based on a SELINUX_STATUS setting.  Nothing in AOSP appears to check or use the property, so it is not propagated down to SELinux presently, but it could conceivably be used by some other component to set the SELinux enforcing mode at boot.
+
 
+
We have added a buildsebundle tool to our external/sepolicy project to support building the policy bundle file and metadata file required by the ConfigUpdate mechanism and packaging them into a zip file that can be pushed to the device.  We have also extended SEAdmin to support taking one of these zip files, unzip it, and generate the Intent to trigger the policy update.  The use of a zip file to package the bundle and the metadata file isn't necessary but is merely a convenience for delivering the files to the device.  SEAdmin was also extended to extract the certificate from otacerts.zip on the device and insert it into the Settings.Secure database on boot, which is required for the ConfigUpdate code to verify the bundle signature.  Normally this would be handled in some other way as part of the original provisioning of the device.
+
 
+
This new mechanism does not provide the full functionality of SEAdmin; in particular, it does not yet provide a way to set enforcing mode (in a way propagated down to SELinux), to set policy booleans, or to manage the middleware MAC (MMAC) mechanisms.  Thus, the device admin APIs and corresponding SEAdmin functionality are still provided on our seandroid and seandroid-4.3 branches.  We may be able to eventually eliminate the need for those APIs through extensions to the SELinuxPolicyInstallReceiver code to support the full range of functionality of SEAdmin.
+
 
+
You can run buildsebundle without any arguments to see a help message.
+
Sample usage is shown below (presumes you already have built SE for Android):
+
<pre>
+
source build/envsetup.sh
+
lunch full_manta-userdebug
+
make buildsebundle
+
buildsebundle -k build/target/product/security/testkey.pk8 out/target/product/manta/root/*
+
adb push selinux_bundle.zip /sdcard/
+
</pre>
+
 
+
Note that buildsebundle will look for files with the expected names for the SELinux policy files from the list of
+
files passed to it and will ignore any others, which is why we can pass a wildcard path above.  All of the SELinux
+
policy files must be included in the update; you cannot only include a subset of them.  Also note that the key specified above is the
+
testkey used by default in AOSP builds; if you generated and are using your own keys for a production device, you will need to specify
+
the path to it.  If you create subsequent policy update bundles, you will need to specify the -v option to buildsebundle with an incrementing
+
version number in order for the update to be applied; the default is 1.  You can optionally specify a -r option with
+
the hash of the previously installed bundle to make installation dependent on a specific prior update.  The hash can be computed via openssl sha512 update_bundle, where update_bundle can be extracted from the zip file for the prior update.
+
 
+
Then, on the device, run SEAdmin, select SELinux Policy under UPDATE OPTIONS, and select Reload Kernel Policies.
+
From an adb shell, check dmesg to confirm that policy was reloaded from /data/security/current/sepolicy,
+
and check the contents of /data/security to see the unpacked policy files under /data/security/contexts.
+
 
+
== Addressing Hidden Denials ==
+
 
+
If you encounter permission denials while in enforcing mode but do not see any avc: denied messages in the dmesg output
+
or /data/misc/audit/audit.log (if running auditd), then you may need to install a modified policy with dontaudit rules
+
stripped in order to find the underlying cause.  The dontaudit rules are normally present to avoid noise in the audit logs
+
from harmless application probing or permission tests used to select a different code path rather than being required for
+
operation.  To install and load the policy with dontaudit rules removed, do the following:
+
<pre>
+
cd out/target/product/<device>/obj/ETC/sepolicy_intermediates
+
adb push sepolicy.dontaudit /data/local/tmp
+
adb shell
+
su
+
cd /data/local/tmp
+
mkdir /data/security/dontaudit
+
cp sepolicy.dontaudit /data/security/dontaudit/sepolicy
+
cd /data/security
+
ln -s dontaudit current
+
setprop selinux.reload_policy 1
+
</pre>
+
 
+
Then re-test the operation that was failing and collect the avc: denied messages from dmesg or
+
/data/misc/audit/audit.log.  Be careful to not blindly allow all such permissions
+
as many of them will be unnecessary and not directly relevant to the operation that was failing.
+
When you are finished testing, revert to the original policy as follows:
+
<pre>
+
adb shell
+
su
+
rm /data/security/current
+
setprop selinux.reload_policy 1
+
</pre>
+
 
+
== Running the CTS ==
+
 
+
If you want to run the Android Compatibility Test Suite (CTS) with SE for Android, you should follow the
+
standard instructions as per
+
http://source.android.com/compatibility/.
+
 
+
Additionally, you will need to set the android_cts policy boolean to enable certain policy rules that
+
are specific to the CTS instrumentation that runs on the device, and you will need to enable enforcing mode
+
if you want to test the impact of an enforcing SE for Android system.  This can be done by executing the following
+
commands before running the CTS.  You should make sure you can run the CTS successfully in permissive mode before
+
trying enforcing mode.
+
<pre>
+
adb shell su 0 setsebool android_cts=1
+
adb shell su 0 setenforce 1
+
</pre>
+
 
+
You can also add the setsebool and setenforce commands to your init.rc file to cause them to be executed automatically
+
on each boot of the device, or you can set the booleans and enforcing status using SEAdmin.
+
 
+
You may wish to collect any permission denials and log messages that occur during the CTS execution for later use in
+
diagnosing failures and amending the policy to better support the CTS.  Policy changes that are specific to the CTS
+
instrumentation on the device should go into the sepolicy/cts.te file within the if (android_cts) conditional block, while
+
generic changes suitable for production devices should be integrated into the appropriate policy files.
+
<pre>
+
adb shell su 0 cat /proc/kmsg > dmesg.txt &
+
adb shell logcat *:E > log.txt &
+
</pre>
+
 
+
== Middleware MAC ==
+
 
+
In addition to the SELinux enhancements to Android, we have a set of extensions to the Android middleware that provide different forms of mandatory restrictions over the Android permissions and Inter-Component Communication (ICC) model.  These extensions are collectively referred to as middleware MAC or MMAC.  One of these MMAC mechanisms, Install-time MAC, is available in our master-based seandroid branch and all of our release version-based seandroid-4.x.y branches.  A second MMAC mechanism, Enterprise Operations (EOps), based on the AppOps functionality introduced in Android 4.3, has been recently committed to our master-based seandroid branch and our 4.3-based seandroid-4.3 branch.  Install-time MAC and EOps are described further below.
+
 
+
We have also explored several experimental MMAC mechanisms that are only available in their own separate feature branches.  These include Permission Revocation (revoke-perms branch), Intent MAC (intent_mac branch), and Content Provider MAC (cp_mac branch), all of which are forked from the master-based seandroid branch. None of these experimental extensions are still being actively developed and we are presently investigating replacing their functionality through a combination of the AppOps and IntentFirewall
+
functionality first introduced in Android 4.3.
+
 
+
=== Install-time MAC ===
+
 
+
This MMAC mechanism applies an install-time check of app permissions against a MAC policy configuration (found in
+
external/sepolicy/mac_permissions.xml in the source tree and as etc/security/mac_permissions.xml on the system image).
+
The persist.mmac.enforce system property controls whether the MAC restrictions are enforced; this can be set via
+
SEAdmin app or via setprop.  If permissive, then the mechanism will simply log MAC denials, which can be viewed and saved via SEAdmin.  An updated mac_permissions.xml configuration can be pushed to /data/security/mac_permissions.xml (in our code, or /data/system/mac_permissions.xml in 4.3) to override the configuration on the system image on the next boot.  This support is included in the master-based seandroid branch and all release version-based seandroid-4.x.y branches.  The setool program can be used to generate policy stanzas for mac_permissions.xml, or to check whether a given apk would violate a given mac_permissions.xml configuration.
+
<pre>
+
setool --build whitelist /path/to/foo.apk
+
setool --policy /path/to/mac_permissions.xml /path/to/foo.apk
+
</pre>
+
 
+
=== Enterprise Operations (EOps) ===
+
 
+
This MMAC mechanism builds upon the AppOps functionality introduced in Android 4.3 and extends it to support enterprise
+
control over certain runtime application operations.  EOps can be configured via the external/sepolicy/eops.xml file in the source tree (installed as /system/etc/security/eops.xml).  EOps leverages the existing seinfo tags that are assigned to apps upon installation by the Install-time MAC mechanism as a way to group apps into equivalence classes for identifying what operations to block.  Operations identified in the eops.xml configuration are locked and cannot be allowed via AppOps.  The Settings app
+
has been modified to enable the hidden AppOps interface and to show what operations are locked by the EOps mechanism, but
+
the EOps mechanism is not in any way dependent on the modified Settings app for operation.  An updated eops.xml configuration can be pushed to /data/security/eops.xml to override the configuration under /system/etc/security on the next boot.  This support is included in the master-based seandroid branch and the 4.3-based seandroid-4.3 branch.
+
Work is in progress to port this support to Android 4.4.
+
 
+
== For More Information ==
+
 
+
Questions about SE for Android may be directed to the public seandroid-list AT tycho.nsa.gov mailing list.
+
You can subscribe to the list by sending an email containing "subscribe seandroid-list" as the body (not the subject)
+
to majordomo AT tycho.nsa.gov.  You must subscribe before posting to seandroid-list AT tycho.nsa.gov.  List archives are available
+
via majordomo (using the index and get commands).  The archives can also be read or searched via [http://marc.info/?l=seandroid-list MARC] or [http://dir.gmane.org/gmane.comp.security.seandroid GMANE] or [http://www.mail-archive.com/seandroid-list@tycho.nsa.gov/info.html mail-archive.com].
+
 
+
You may also send private email to our team alias, seandroid AT tycho.nsa.gov.
+
However, whenever possible, please use the public mailing list.
+
 
+
Early SE for Android discussions occurred on the public selinux mailing list prior to the creation of the seandroid-list.
+
You can search the selinux mailing list archives at [http://marc.info/?l=selinux MARC] or [http://dir.gmane.org/gmane.comp.security.selinux GMANE] for "android" if you want to read those early discussions.
+
 
+
== External Tools ==
+
 
+
* [https://bitbucket.org/billcroberts/fixup/overview fixup] : script for converting allow rules to use macros
+
* [https://bitbucket.org/joshua_brindle/sepolicy-inject sepolicy-inject] : tool for adding rules to an existing binary policy
+
* [https://bitbucket.org/joshua_brindle/packages-apps-seandroidadmin seandroidadmin] : fork of SEAdmin for GS4
+
 
+
== External Documentation ==
+
  
* [http://selinuxproject.org/page/NB_SEforAndroid_1 SELinux Notebook section on SE for Android]
+
Further talks describing the impact of SELinux on Android security and further SELinux development in Android include:
 +
* ioctl command whitelisting in SELinux, Linux Security Summit 2015, Aug 2015. [http://kernsec.org/files/lss2015/vanderstoep.pdf Slides]
 +
* Android: protecting the kernel, Linux Security Summit, Aug 2016. [http://events17.linuxfoundation.org/sites/events/files/slides/Android-%20protecting%20the%20kernel.pdf Slides]
 +
* Honey I Shrunk the Attack Surface: Adventures in Android Security Hardening, Black Hat USA 2017, July 2017. [https://www.blackhat.com/docs/us-17/thursday/us-17-Kralevich-Honey-I-Shrunk-The-Attack-Surface-Adventures-In-Android-Security-Hardening.pdf Slides]
 +
* SELinux in Android Oreo or: How I Learned to Stop Worrying and Love Attributes, Linux Security Summit 2017, Sep 2017. [http://events17.linuxfoundation.org/sites/events/files/slides/LSS%20-%20Treble%20%27n%27%20SELinux_0.pdf Slides]
 +
* Year in Review: Android Kernel Security, Linux Security Summit 2018, Aug 2018. [https://events.linuxfoundation.org/wp-content/uploads/2017/11/LSS2018.pdf Slides]
  
    Android is a trademark of Google Inc.
+
(Android is a trademark of Google LLC)

Revision as of 12:50, 5 October 2018

Security Enhancements (SE) for Android™ was a NSA-led project that created and released an open source reference implementation of how to enable and apply SELinux to Android, made the case for adopting SELinux into mainline Android, and worked with the Android Open Source Project (AOSP) to integrate the changes into mainline Android. As a result, SELinux is now a core part of Android. See https://source.android.com/security/selinux/ for further information on SELinux in Android.

SE for Android was originally called Security Enhanced Android (SE Android) but was renamed to comply with the Android brand guidelines. Hence, you will see the older name in many of the presentations and papers below.

SE for Android used to maintain its own source code repositories on bitbucket.org but these have been removed since the code has all been merged to AOSP.

Presentations and papers describing SE for Android included:

  • The Case for SE Android, Linux Security Summit 2011, Sep 2011. Slides
  • The Case for Security Enhanced (SE) Android, Android Builders Summit 2012, Feb 2012. Slides
  • Security Enhanced (SE) Android, LinuxCon North America 2012, Aug 2012. Slides
  • Middleware MAC for Android, Linux Security Summit 2012, Aug 2012. Slides
  • Security Enhanced (SE) Android: Bringing Flexible MAC to Android, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013. Paper and Slides
  • Laying a Secure Foundation for Mobile Devices, 20th Annual Network and Distributed System Security Symposium (NDSS '13), Feb 2013. Slides
  • Security Enhancements (SE) for Android, Android Builders Summit 2014, Apr 2014. Slides
  • Protecting the Android TCB with SELinux, Linux Security Summit 2014, Aug 2014. Slides
  • SELinux in Android Lollipop and Marshmallow, Linux Security Summit 2015, Aug 2015. Slides

Further talks describing the impact of SELinux on Android security and further SELinux development in Android include:

  • ioctl command whitelisting in SELinux, Linux Security Summit 2015, Aug 2015. Slides
  • Android: protecting the kernel, Linux Security Summit, Aug 2016. Slides
  • Honey I Shrunk the Attack Surface: Adventures in Android Security Hardening, Black Hat USA 2017, July 2017. Slides
  • SELinux in Android Oreo or: How I Learned to Stop Worrying and Love Attributes, Linux Security Summit 2017, Sep 2017. Slides
  • Year in Review: Android Kernel Security, Linux Security Summit 2018, Aug 2018. Slides

(Android is a trademark of Google LLC)