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
License for changes to the Android (Linux) Kernel
Getting access to the source code
To get access to the sourcecode, please send the following information to: anadkarni@ncsu.edu:
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:
Verify that you can connect to wspr-git via ssh.
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.
Then, check out the Weir manifest, which is the first step in cloning the android repositories modified by Weir.
Synchronize the repository again, which will download Weir’s source code for Android 5.0.1:
Finally, download the Weir 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:
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.
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:
Now, build the kernel
Copy the newly built kernel to replace the hammerhead kernel included in the Android framework source, and build the source again.
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.
Executing and Testing Weir
As overlayfs is yet not compatible with SELinux, we need to set SELinux to permissive mode, as follows:
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.
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.
To test or use Weir’s classes, first add the following jar file as an external library to your test application:
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.:
- Start the BCloud app.
- Select “Add Tag”, which adds the secret tag created by BCloud.
- Select “Share”, and select the messaging app from the chooser screen.
- Then, press the home button, to go back to the home screen.
- Start the Weir_Test_Unlabeled app, and repeat steps 2->3.
- 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.
- 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:
- 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.
- 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).
- 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.