Weir: Practical DIFC Enforcement on Android

Smartphone users often use private and enterprise data with untrusted third party applications. The fundamental lack of secrecy guarantees in smartphone OSes, such as Android, exposes this data to the risk of unauthorized exfiltration. A natural solution is the integration of secrecy guarantees into the OS, but prior Android-DIFC systems have faced many challenges in making their enforcement both secure and backwards compatible with unmodified apps. Our system, Weir, uses a technique called “lazy poly-instantiation” to make implicit label propagation (i.e., “floating labels”) context sensitive, thereby solving many practicality issues with existing DIFC labeling and enforcement.

Licensing Information

License for changes to the Android platform

Copyright (c) 2016, North Carolina State University 
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in the
      documentation and/or other materials provided with the distribution.
    * Neither the name of the North Carolina State University nor the
      names of its contributors may be used to endorse or promote products
      derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL NORTH CAROLINA STATE UNIVERSITY BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

License for changes to the Android (Linux) Kernel

Copyright (C) 2016  North Carolina State University

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

Getting access to the source code

To get access to the sourcecode, please send the following information to: anadkarni@ncsu.edu:

 Your Name
 Your Affiliation
 Your SSH Public Key (please attach the .pub file to the email.)
 Intended Use: non-commercial, commercial or academic

Please note that we will publish your affiliation (e.g., your university or company) on our website once we fulfill your request. If you do not want this information to appear on our website please tell us in your request email.

We will notify you as soon as we have fulfilled your request.

Additionally, to configure your ssh client to pull source code from our server, place the following lines in your ~/.ssh/config file:

Host wspr-git
 HostName wspr-git.csc.ncsu.edu
 IdentityFile ~/.ssh/<your private key file>

Verify that you can connect to wspr-git via ssh.

$ ssh git@wspr-git info

Downloading the source code

First, establish the AOSP build environment as described here.

Then, create a working directory for weir, and download the source code for android-5.0.1_r1 inside it. This is the unmodified Android source code; we will download Weir’s modifications in the next few steps.

Optional Note: Syncing the Android platform code will take significant time, so start syncing in a screen to be safe.

$ mkdir Weir
$ cd Weir
$ repo init -u https://android.googlesource.com/platform/manifest -b android-5.0.1_r1
$ repo sync

Then, check out the Weir manifest, which is the first step in cloning the android repositories modified by Weir.

$ git clone git@wspr-git:weir/manifest
$ mkdir .repo/local_manifests
$ cp manifests/local_manifest.xml .repo/local_manifests/

Synchronize the repository again, which will download Weir’s source code for Android 5.0.1:

$ repo sync

Finally, download the Weir kernel

$ git clone git@wspr-git:weir/kernel/msm.git kernel

Building Weir

Building the Android framework

First, download the proprietary binaries needed for building for the Nexus 5, as shown here.

Then, in the working directory (i.e., “Weir”), execute the following commands:

$ . build/envsetup.sh
$ lunch aosp_hammerhead-userdebug
$ make -j8

Compiling the Kernel

Weir needs the weir kernel to function. In the directory where we downloaded the weir kernel (Weir/kernel/), configure the kernel using the prebuilt toolchain supplied by the Android source code, using the weir defconfig file included in the weir kernel source.

$ cd kernel
$ make ARCH=arm CROSS_COMPILE=../prebuilts/gcc/linux-x86/arm/arm-eabi-4.8/bin/arm-eabi- hammerhead_weir_defconfig

Alternately, you could also separately download the Android toolchain and include it in the $PATH environment variable, which would allow you to configure the kernel without the absolute path for the toolchain, as follows:

$ make ARCH=arm CROSS_COMPILE=arm-eabi- hammerhead_weir_defconfig

Now, build the kernel

$ make -j8 ARCH=arm CROSS_COMPILE=arm-eabi-

Copy the newly built kernel to replace the hammerhead kernel included in the Android framework source, and build the source again.

$ cp arch/arm/boot/zImage-dtb ../device/lge/hammerhead-kernel/zImage-dtb
$ cd ..
$ lunch aosp_hammerhead-userdebug
$ make -j8

Flashing Weir to a device

First, ensure that the bootloader of the Nexus 5 is unlocked. Then, use fastboot to flash the newly built images to the device.

$ cd Weir
$ fastboot flash system out/target/product/hammerhead/system.img
$ fastboot flash userdata out/target/product/hammerhead/userdata.img
$ fastboot flash boot out/target/product/hammerhead/boot.img
$ fastboot flash reboot

Executing and Testing Weir

As overlayfs is yet not compatible with SELinux, we need to set SELinux to permissive mode, as follows:

$ adb shell su 0 setenforce 0

During development, we wrote some simple scripts to automatically set the selinux enforcement, copy adb logs, etc. The scripts are available in the scripts repository.

$ git clone git@wspr-git:weir/examples/scripts.git

Additionally, we have also included two example applications, “bcloud” and “weir_test_unlabeled”, that can be used to start other apps from a labeled and unlabeled context respectively.

$ git clone git@wspr-git:weir/examples/bcloud.git
$ git clone git@wspr-git:weir/examples/weir_test_unlabeled.git

To test or use Weir’s classes, first add the following jar file as an external library to your test application:

$ cp out/target/common/obj/JAVA_LIBRARIES/android_stubs_current_intermediates/classes.jar test_app/libs/

The simplest way to observe how Weir’s polyinstantiation works, is to perform the following steps with our test examples. The adb logs printed by Weir may also help your understanding of the system, so keep recording the logs while running the test.:

  1. Start the BCloud app.
  2. Select “Add Tag”, which adds the secret tag created by BCloud.
  3. Select “Share”, and select the messaging app from the chooser screen.
  4. Then, press the home button, to go back to the home screen.
  5. Start the Weir_Test_Unlabeled app, and repeat steps 2->3.
  6. At this point, if you look at the recents screen, you will see two instances of the Messaging app, specifically its compose activity. Each instance will show the text it received from its respective secrecy context in its “message” textbox; i.e., the instances started by BCloud and the unlabeled app will show different text.
  7. If you look at the logs, you will also see that the two instances of the messaging app, plus the sms provider, are running in different context-specific processes.

Device support

Weir has been built, developed and tested with the hammerhead branch of the msm Linux/Android 3.4 kernel. As a result, we support the LG Nexus 5 out of the box. Porting Weir to other kernels should be straightforward.


Additional Release Notes

We are fixing bugs as and when we notice them, and any bug reports will be appreciated. Some additional notes for this release are as follows:

  1. For quick debugging (w/o re-flashing the device state after tests), our prototype initializes the internal state of the Weir Manager service afresh on every reboot. As a result, to perform different tests, simply rebooting the device, and reinstalling our test applications is sufficient to give us a fresh start. A production version of Weir will have to make Weir Manager’s internal state persist by writing it to storage before shutdown.
  2. Our xattr enforcement is set to auditing mode, primarily because of point 1 (as system apps cannot be easily reinstalled without flashing, and their storage gets labeled in executions of Weir). Denials can be observed in the kernel logs (see dmesg_logs.sh).
  3. Our prototype works with unmodified system providers, and has been tested with contacts and messaging providers as a part of our experiments. Other providers should be no different. The media provider may be an exception, and may have to be treated like system services. That is, the media provider reads directories in the /media directory that is not polyinstantiated by Weir, as Weir only remounts the sdcard and the internal app directory. We are working on patching the media provider in a manner similar to system services.