What’s in Your Dongle and Bank Account? Mandatory and Discretionary Protection of Android External Resources
1. Jawbone Attack
Below is a demo which shows that UP band and its app provides no secure bindings to protect user's private activity information.
2. SEACAT and SMS
Without SEACAT, any app with SMS_READ or RECEIVE_SMS permission can read messages from any sender, including password reset messages. Here we show how easy it is for an app with RECEIVE_SMS permission to reset a Facebook account and how SEACAT can prevent such access assuring SMS messages are delivered to only authorized apps.
3. A. Bluetooth misbonding on AOSP
Here we recreate the Bluetooth misbonding attack reported in related work (Naveed et. al. 2014) to show that the attack can still work on a non-SEACAT powered Android phone.
3. B. SEACAT thwarting the Bluetooth misbonding attack
This is a demonstration of SEACAT enabled Android 4.4. SEACAT can dynamically label applications, external resources and associate them with SELinux policies to guarantee the inherent confidentiality between the two endpoints. SEACAT can also enforce static policies on external resources. Here we show how dynamic labelling of apps and resources can be done to thwart the Bluetooth misbonding attack.
4. DAC policy construction
5. Policy syntax
The app-domain associations are kept as in SEAndroid in seapp_contexts for MAC policies and in user_seapp_contexts for DAC policies (For DAC policies the entry is constructed transparently to the user when she selects to label an app during installation). Their syntax is identical.
This is an example of the syntax used to keep the association between a a resource and an SELinux type in seres_contexts for MAC policies and user_seres_contexts for DAC policies (For DAC policies, the entries of user_seres_contexts are constructed transparently to the user. For example this happens when she selects to associate a device with a labelled app during connection-time labelling):