Transcript and

Android Permission
System
Presenter: Yishu Gu, Jackie Wu and Zhengyang Qu
Outlines
 Review and introduction of .apk file
 AndroidManifest.xml file
 Permissions
 Methods to minimize requested permission
 Related research topic
Android .apk file
APK file of facebook android application
Android application
 Androidmanifest.xml
 describes the functionality and
permission declaration of an app
 Classes.dex
 Java source complied into .dex
byte-code file
 META-INF
 Signature information
 Resources.arsc
 Containing precompiled
resources such as binary XML
 Application can start each other
based on Components and Intent
Review：App Component
 Activity
 Single screen
 Work together to for a cohesive user experience
 Service
 Run in background
 Provides a “service” interface between applications
 Content provider
 Manage shared app data
 Other apps can query/modify data if allowed
 Broadcast receiver
 Respond to system-wide broadcast announcements
 Apps can initiate broadcast announcements
Quiz: App Components
Match the component to what it does:
1 Activity
2 Service
3 Content
provider
4 Broadcast
receiver
A) Respond to system-wide
announcements
B) Manage shared app data – other
apps can view/modify is allowed
C) One single “screen” with user
interface
D) Runs in background, interfaces
between applications
Components
 public or private
 Private only components from same app or another app
that runs with same UID
 Exported attribute decides whether the component is
public or private
 True: exported to other apps (public)
 False: not exported to other apps (private)
 Default value depends on if the service contains <intentfilter>
 The default value for Content Provider is true
Intent
 Communication between applications
 Activated components:
 startActivity – launches a new screen
 BroadcastIntent – send to BroadcastReceivers
 bindService – connect to background service
 Specified in the Manifest by IntentFilters
 Filter actions, categories, data, (and priority)
 e.g. action= make a phone call, data = phone number
AndroidManifest.xml
 XML configuration file
 Every application must have it
 Contains:
 application’s name, icon, labels
 Linked libraries
 Application Components:
• Activities – <activity>
• Services – <service>
• Broadcast receivers – <receiver>
• Content providers – <provider>
• Components specify what kind of Intent they accept with an <intent-filter>
• Component has a <intent-filter> in AndroidMainfest.xml file, it’s exposed by
•
•
defalut
• Content provider do not use intents
Permissions
Don’t export app components unless you want other apps on system to interact
with your app
Example AndroidManifest.xml
Android permission model
 Two big goals:
 Inform the user : list all “sensitive” operations before
installing the app
 Mitigate Exploits : limit access to sensitive APIs for
attackers
Quiz: Permissions Goals
 What are two goals of the permission system of
Android?
 Hint 1: User experience
 Hint 2: Permission systems are used because...
Permissions Manifest File
 Permissions are granted at
install time
 All or nothing.
 API-defined permissions in
AndroidManifest.Permissions
class
Permissions Manifest File
 Custom-defined permissions
by developers
 Name conflicts may appear
 Current research on
Android permissions
doesn’t take them into
consideration
Specifying required permissions
e.g. If your application needs access to the Internet, specify the
INTERNET permission
Custom permissions
 Can be used by developers to restrict to various
services/components
 A permission must be declared/created in an application’s
manifest.
 Any application need to possess the required permission for
the call to succeed
Another example for custom permissions
In this example an application signed with the same key can access the service
Permission Protection Levels
 normal
 android.permission.ACCESS_NETWORK_STATE
 android.permission.ACCESS_WIFI_STATE
 Dangerous
 android.permission.INTERNET
 android.permission.ACCESS_FINE_LOCATION
 Signature
 android.permission.HARDWARE_TEST
 android.permission.READ_INPUT_STATE
 SignatureOrSystem
 android.permission.BACKUP
 android.permission.BIND_WALLPAPER
Permission Protection Levels
 There are different permission protection levels available
for apps:
• protectionLevel="normal" – default
• protectionLevel="dangerous" – private user data or
control over the device that can negatively impact the user.
• protectionLevel="signature" – limit access to only apps
signed with the same certificate.
• protectionLevel="signature or system” – device
manufacturers only
Discretionary Access Control (DAC)
 Linux access control
 Based on group/user ID for apps
 Restrict system facilities
 e.g. Wi-Fi access, storage, location
MAC & DAC
 Mandatory access control (MAC, Android permission system)
 Creator of an object does not necessarily have the ability to
determine who has authorized access to it
 Policy typically governed by a central authority, Android reference
monitor in middleware
 Discretionary access control (DAC, Linux low-level
enforcement)
 Individual user (an application) may, at his own discretion,
determine who is authorized to access the objects he creates
Guess permission protection level
 CALL_PHONE
dangerous
 Allows an application to initiate a phone call without going through
the Dialer user interface for the user to confirm the call being
placed.
 CHANGE_NETWORK_STATE dangerous
 Allows applications to change network connectivity state
 BATTERY_STATS
normal
 Allows an application to collect battery statistics
 BROADCAST_SMS
signature
 Allows an application to broadcast an SMS receipt notification
 http://rupertrawnsley.blogspot.com/2011/11/android-permissions-protectionlevels.html
 https://github.com/android/platform_frameworks_base/blob/master/core/res/A
ndroidManifest.xml
Android Permission List
 All included in Manifest.permission class
 latest API version:22
 http://developer.android.com/reference/android/Manifes
t.permission.html
Component Permissions
 Individual components can set their own permissions
 Component permissions take precedence over
application-level permissions
 Any component can access a public component
without specifying a access permission
Permissions in AndroidManifest for components
 activity
 Restricts access to the activity
 Checked when staring activity
 startActivity() and startActivityForResult()
 Throw SecurityException if caller does not have required
permission
Permissions in AndroidManifest for components
 service
 Restricts who can interact with service
 Checked within execution of Context.startService(),
Context.stopService() or Context.bindService()
 Throw a SecurityException when failed
Permissions in AndroidManifest for components
 provider (Content Provider)
 Restrict who can access the data
 Separate read and write permissions
 Checked when performing operations(e.g. query, insert)
 Problem: need grant permissions to certain portions of a Content
Provider's database in short time
 Solution: URI permission
URI permission
 Scenario: email client app
 If an image or sound file attachment attached to a message,
we need to grant corresponding permission to present it
 Solution: User interface app could temporarily grant
permission to the URI that contains an attachment to the
image viewer
 URI turned off by default
 android:grantUriPermissions="true”
 android:grantUriPermissions=”false”
 path
 pathPrefix
 PathPattern
URI permission
 Content provider allow URI permissions to be granted on
the/attachments/ path
 App needs to actually grants these permission
 Set flags in the Intent that allows access
 e.g. Intent.FLAG_GRANT_READ_URI_PERMISSION
Permissions in AndroidManifest for components
 receiver (Broadcast receiver)
 Restricts who can send broadcasts to the BroadcastReceiver
 Check at delivery, after broadcast was sent
 Does not throw exception in case of permission failure
Enforcing permissions in code
 Context.registerReceiver() can be used to register a
BroadcastReceiver dynamically
 Allow senders with MSG_NOTIFY_SEND permission to
send to the registering Broadcast Receiver
Enforcing permissions in code
 Applications can check to see if calling apps have
permissions in code
 Context.checkCallingPermission() and
Context.enforceCallingPermission() can be used in
source code to make sure the calling app holds the
appropriate permission
Question:
What’s the difference between <permission>
and <uses-permission>?
<permission> and <uses-permission>
 <permission>
 Developer are requiring permissions / enforce your own
permission
 Avoid other application to invoke your app
 Protect users’ privacy of your app
Normally used when making a custom permission
 <uses-permission>
 Developer are requesting this permission for app/ seeking the
user’s permission to use some feature of yours
 Users must accept these permissions
 Used when your app actually needs a permission it doesn’t
have normally
Summary
Questions
 Content Providers/<provider> have two separate
permissions. What are they?
 read and write
 Which component will not throw a exception in the
case of permission failure?
 receiver (Broadcast receiver)
Principle of using permissions
 Requesting Permissions
 Minimize the number of permissions that app requests
 Design your app that does not require permissions
 E.g. Rather than using external storage, store data on the
internal storage
 Creating Permissions
 Creating a new permission is uncommon
 If you must create new permissions, consider signature
protection level permission first
Minimize requested permissions
Users don’t like when your app requests too many permissions…
CAMERA
MESSAGES/CONTAC
T
ACCESS_FINE_LOCATIO
N
Only request permissions your app requires
 Why minimize the amount of permissions?
 1/3 of apps request more permission than they need
 Security vulnerabilities can expose protected data
 User preferences
 Sometimes permissions aren’t required
 Getting a picture from the camera
 Sending an SMS through the SMS app
 Permissions can be temporarily granted to apps by
content providers
 Letting the user pick a contact to share with your app
Get a camera pic without CAMERA permission
Start the SMS app with a filled-in destination and
message
Does not require the SEND_SMS
Let the user choose a contact with
ACTION_GET_CONTENT
Related Research
 Topic: Android Application Static Malware Detection
Module
 Main process
1. Extract permissions as features for each .apk file
2. Use machine learning algorithm to classify samples
3. Modify algorithm and features for improving accuracy
Background
Android Malware are
growing rapidly
- Over 97% mobile threats
coming from Android Mobile Apps
- penetrate while repacking,
updating, downloading
Feature extraction
Sample definition
@relation testset
@attribute ACCESS_CHECKIN_PROPERTIES {0,1} //didn’t defined 0
@attribute ACCESS_COARSE_LOCATION {0,1}
//shown 1
@attribute ACCESS_FINE_LOCATION {0,1}
….
@attribute malware{B, M} // benign, malicious
@data
0,1,1,0,1,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,…,0,0,0,1,0,0,1,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,B
Total 145 permissions in API 19
Sample: 250 malware and 250 benign software
Malware
Benign
Set weight to permission and permission combinations
(part of original table)
Sensitive permission or permission
combinations
weight
INTERNET
1
READ_PHONE_STATE
2
RECEIVE_BOOT_COMPLETED
2
READ_SMS
12
RECEIVE_SMS ∧ SEND_SMS
30
READ_PHONE_STATE ∧ INTERNET
20
GET_ACCOUNTS ∧ INTERNET
20
READ_LOGS ∧ INTERNET
20
0,1,1,0,1,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,…,0,0,0,1,0,0,1,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,26,B
Note: The number 26 is sum of permission weight in this apk file
Top 10 Bad Permissions
(on Google Play I/0 2012)
1.
SEND_SMS, RECEIVE_SMS
2.
SYSTEM_ALERT_WINDOW
3.
READ_HISTROY_BOOKMARKS WRITE_HISTROY_BOOKMARKS
4.
READ_CONTACTS, WRITE_CONTACTS, READ_CALENDAR, WRITE_CALENDAR
5.
CALL_PHONE
6.
READ_LOGS
7.
ACCESS_FINE_LOCATION
8.
GET_TASKS
9.
RECEIVE_BOOT_COMPLETED
10. CHANGE_WIFI_STATE
Thank you for your time!