This document discusses Android security and outlines some of its key features and challenges. It describes how Android extends traditional UNIX security models through permissions and how permissions are enforced at different levels of the software stack, from installation to system calls to services. However, it notes some problems with Android's permission approach including coarse-grained permissions and difficulty updating devices. It proposes possible improvements such as better permission documentation and expanding security scanning.

1. Android
Security
Jesus Cox Richard Rand
Jonathan Heide Luis Rodriguez

2. Overview
• Built on the Linux kernel.
• Android is open source, meaning that developers can
customize the operating system to suit each device.
• As a result, Android has been adapted to a wide array
of mobile devices, with varying hardware, price
points, and market segments.
• Manufacturers have also been able to experiment
with many styles of Graphical User Interfaces.
• This diversity has been a security challenge, because
it takes longer to update the OS to fix security flaws.

3. Permissions
ACCESS_CHECKIN_PROPERTIES Allows read/write access to the "properties" table in the
Traditionally UNIX security checkin database, to change values that get uploaded.
is about protecting users ACCESS_COARSE_LOCATION
location
Allows an application to access coarse (e.g., Cell-ID, WiFi)
from each other and the ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location
ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location
operating system from provider commands
ACCESS_MOCK_LOCATION Allows an application to create mock location providers for
users, by limiting the testing
ACCESS_NETWORK_STATE Allows applications to access information about networks
permissions of certain ACCESS_SURFACE_FLINGER Allows an application to use SurfaceFlinger's low level
users. ACCESS_WIFI_STATE
features
Allows applications to access information about Wi-Fi
networks
ACCOUNT_MANAGER Allows applications to call into AccountAuthenticators.
ADD_VOICEMAIL Allows an application to add voicemails into the system.
Android extends this AUTHENTICATE_ACCOUNTS Allows an application to act as an AccountAuthenticator for
concept to protect the BATTERY_STATS
the AccountManager
Allows an application to collect battery statistics
user from apps they BIND_APPWIDGET Allows an application to tell the AppWidget service which
application can access AppWidget's data.
install. BIND_DEVICE_ADMIN Must be required by device administration receiver, to
ensure that only the system can interact with it.
BIND_INPUT_METHOD Must be required by an InputMethodService, to ensure that
only the system can bind to it.
BIND_REMOTEVIEWS Must be required by a RemoteViewsService, to ensure that
only the system can bind to it.
BIND_TEXT_SERVICE Must be required by a TextService (e.g.
BIND_VPN_SERVICE Must be required by an VpnService, to ensure that only the
system can bind to it.
BIND_WALLPAPER Must be required by a WallpaperService, to ensure that

4. Permissions
During installation, each
application requests all the
permissions it may need to run.
If the user chooses to grant the
permissions and install, the
application is assigned a unique
UID and user name (of the form
“app_#”), and a set of groups that
correspond to its permissions.

5. How Zygote Sets UIDS and GIDS:
[android/platform/dalvik.git]/vm/native/dalvik_system_Zygote.cpp
Set by Zygote. How?
static pid_t forkAndSpecializeCommon(const u4* args, bool
isSystemServer)
Before the application is {
run, the spawning process, pid_t pid;
uid_t uid = (uid_t) args[0];
zygote, uses standard UNIX gid_t gid = (gid_t) args[1];
system calls to set its UID ArrayObject* gids = (ArrayObject *)args[2];
……
and GIDs. pid = fork();
if (pid == 0) {
/* The child process */
……
err = setgroupsIntarray(gids);
……
err = setgid(gid);
……
err = setuid(uid);
……

6. How Permissions are Enforced – In the Kernel:
Example: socket()
[android/platform/system/core.git]/include/private/android_filesystem_config.h
Enforced by kernel. How?
/* The 3000 series are intended for use as supplemental group id's
only. */
/* They indicate special Android capabilities that the kernel is aware
On application install, of. */
AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */
some system permissions AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap
are mapped to UNIX sockets */
AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */
groups with standardized AID_NET_RAW 3004 /* can create raw INET sockets */
gids.

7. How Permissions are Enforced – In the Kernel:
Example: socket()
Enforced by kernel. How? android-3.3/net/ipv4/af_inet.c
120 #ifdef CONFIG_ANDROID_PARANOID_NETWORK
On application install, some 121 #include <linux/android_aid.h>
system permissions are 122
mapped to UNIX groups 123 static inline int current_has_network(void)
with standardized gids. 124 {
125 return in_egroup_p(AID_INET) ||
capable(CAP_NET_RAW);
The kernel has been 126 }
modified to check the GIDs 127 #else
128 static inline int current_has_network(void)
of the calling process during
129 {
those system calls which 130 return 1;
need protection. 131 }
http://blog.appuarium.com/2011/06/23/ho
132 #endif
w-android-enforces-android-permission-
internet/

8. How Permissions are Enforced – In Services:
Example: Camera
Enforced by the Camera services/camera/libcameraservice/CameraService.cpp
service. How?
status_t CameraService::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) {
On application install, // Permission checks
switch (code) {
some system permissions case BnCameraService::CONNECT:
are mapped to UNIX const int pid = getCallingPid();
groups with standardized const int self_pid = getpid();
gids. if (pid != self_pid) {
// we're called from a different process, do the real check
if (!checkCallingPermission(
http://www.netmite.com/ String16("android.permission.CAMERA"))) {
android/mydroid/system/c const int uid = getCallingUid();
ore/include/private/androi LOGE("Permission Denial: "
"can't use the camera pid=%d, uid=%d", pid, uid);
d_filesystem_config.h return PERMISSION_DENIED;
…..

9. How Permissions are Enforced – In Activities:
Example: Phone
Enforced by the Phone platform_packages_apps_phone/AndroidManifest.xml
<activity android:name="OutgoingCallBroadcaster"
activity. How?
android:permission="android.permission.CALL_PHONE">
<!-- CALL action intent filters, for the various ways
An XML attribute called of initiating an outgoing call. -->
<intent-filter>
permission: <action android:name="android.intent.action.CALL" />
http://developer.android. <category
com/guide/topics/manife android:name="android.intent.category.DEFAULT" />
st/activity-element.html <data android:scheme="tel" />
……..

10. Remote Kill
REMOVE_ASSET
INSTALL_ASSET
http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

11. Other Security Features
• Application signing
• Allows a developer to share resources between their apps
• Bouncer (New)
• Automatically scans and tests apps on the market for suspicious
behavior
• Reporting of Suspicious Apps
• Android Security Team

13. PROBLEMS WITH ANDROID’S
APPROACH
• Many users are unable to weigh potential risks when granting
permissions to an application
• No way to be sure that an application will act appropriately based on
the given permission
• Coarse grained – users must allow all possible permissions for an app
or developers must create multiple versions.
• Developers tend to ask for more permissions than they need because
of sparse documentation.
• Sophisticated users are limited by the standard permissions made
available by Android unless they root the phone.
• “Remote kill“ removes autonomy from the user.
• Difficulty of rolling out OS updates causes vulnerabilities to stick
around on some devices forever.
• Apps can access external storage without permissions.

14. Google was not happy with this report.
http://www.mcafee.com/us/resources/reports/rp-securing-mobile-devices.pdf

15. Possible Improvements
• Some of the fears about malware on Android are generated by
antivirus companies to drum up sales
• Require a new permission to read photos or world_readable files
in general on external storage
• Tighten licensing requirements of Android name and imagery
around security and updates
• Fix documentation so developers have a better idea of what
permissions they need
• Use Stowaway to scan the store for apps that take more
permissions than they need, and inform the developers
• Extend Bouncer to unofficial stores to find more Trojan Horses
and protect more users