Android Permission System

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
com.facebook.katana_085912 Androidmainifest.xml Classes.dex META-INF 3

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 Service Content provider
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 Review the different component types and see the permission use in their tags App components are the essential building blocks of an Android app. Each component is a different point through which the system can enter your app. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your app's overall behavior. There are four different types of app components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed. Here are the four types of app components: For example, an app might have one activity that shows a list of new s, another activity to compose an , and another activity for reading s. Although the activities work together to form a cohesive user experience in the app, each one is independent of the others. As such, a different app can start any one of these activities (if the app allows it). For example, a camera app can start the activity in the app that composes new mail, in order for the user to share a picture. Service A service is a component that runs in the background to perform long-running operations or to perform work for remote processes.(Downloading a file, playing music, tracking location, etc.) A service does not provide a user interface. For example, a service might play music in the background while the user is in a different app, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it. Core functionality often implemented as Service components eg. Location API, Alarm service Content provider A content provider manages a shared set of app data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access. Through the content provider, other apps can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the user's contact information. As such, any app with the proper permissions can query part of the content provider to read and write information about a particular person. Content providers are also useful for reading and writing data that is private to your app and not shared. For example, the Note Pad sample app uses a content provider to save notes. Broadcast provider A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Apps can also initiate broadcasts—for example, to let other apps know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event.

Quiz: App Components Match the component to what it does: 1 Activity
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 1 Activity 2 Service 3 Content provider 4 Broadcast receiver Review the different component types and see the permission use in their tags App components are the essential building blocks of an Android app. Each component is a different point through which the system can enter your app. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your app's overall behavior. There are four different types of app components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed. Here are the four types of app components: For example, an app might have one activity that shows a list of new s, another activity to compose an , and another activity for reading s. Although the activities work together to form a cohesive user experience in the app, each one is independent of the others. As such, a different app can start any one of these activities (if the app allows it). For example, a camera app can start the activity in the app that composes new mail, in order for the user to share a picture. Service A service is a component that runs in the background to perform long-running operations or to perform work for remote processes.(Downloading a file, playing music, tracking location, etc.) A service does not provide a user interface. For example, a service might play music in the background while the user is in a different app, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it. Core functionality often implemented as Service components eg. Location API, Alarm service Content provider A content provider manages a shared set of app data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access. Through the content provider, other apps can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the user's contact information. As such, any app with the proper permissions can query part of the content provider to read and write information about a particular person. Content providers are also useful for reading and writing data that is private to your app and not shared. For example, the Note Pad sample app uses a content provider to save notes. Broadcast provider A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Apps can also initiate broadcasts—for example, to let other apps know that some data has been downloaded to the device and is available for them to use. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. More commonly, though, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work. For instance, it might initiate a service to perform some work based on the event. 6

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 <intent- filter> The default value for Content Provider is true UID android: export true other applications can interact with it False only components of the same application or with same user ID can start the service or bind to it Default value depends on if the service contains <intent-filter> The default exported value for Content Providers is true. Because the primary purpose of a Content Provider is to share information between apps, it is assumed that these should be public and accessible by other apps.

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 The core components of an application (its activities, services, and broadcast receivers) are activated by intents. An intent is a bundle of information (anIntent object) describing a desired action — including the data to be acted upon, the category of component that should perform the action, and other pertinent instructions. Android locates an appropriate component to respond to the intent, launches a new instance of the component if one is needed, and passes it the Intent object. Components advertise their capabilities — the kinds of intents they can respond to — through intent filters. Since the Android system must learn which intents a component can handle before it launches the component, intent filters are specified in the manifest as <intent-filter> elements. A component may have any number of filters, each one describing a different capability. An intent that explicitly names a target component will activate that component; the filter doesn't play a role. But an intent that doesn't specify a target by name can activate a component only if it can pass through one of the component's filters.

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 It describes the components of the application the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities(for example, which intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched. Permission that others are required to have in order to interact with the application’s components.

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 At install time each application requests a list of permissions The permission here refers to <user-permission>

Permissions Manifest File
Custom-defined permissions by developers Name conflicts may appear Current research on Android permissions doesn’t take them into consideration At install time each application requests a list of permissions The permission here refers to <user-permission>

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 Component Permissions : Individual components can set their own permissions, restricting which other component can access them Limit access to an exported component by permission The name of a permission that that an entity must have in order to launch the service or bind to it. If a caller of startService(), bindService(), or stopService(), has not been granted this permission, the method will not work and the Intent object will not be delivered to the service. In the service tag, we defined android:permission = com.example.awesome.EXAMPLE_PERM, with these been done, no external component can launch this service or bind to it unless they have this permission. Without this permission if your component is service it cannot be bind to. And intent-receivers will ignore all the messages sents from sendbroadcast method unless the sender has the permission

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 There is only name attribute within the permission tag while there are more than that We can define icon label, permission group and also protection level within the tag  android.permission.INTERNET  android.permission.BIND_WALLPAPER Allows an application to control the backup and restore process. <p>Not for use by third-party applications. @hide pending API council --> android.permission.BACKUP  android.permission.HARDWARE_TEST

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 protectionLevel="normal" – A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. This is the default protection level. The default value. A lower-risk permission that gives requesting applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application at installation, without asking for the user's explicit approval (though the user always has the option to review these permissions before installing). protectionLevel="dangerous" – A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. Because this type of permission introduces potential risk, the system may not automatically grant it to the requesting application. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities. protectionLevel="signature" – a permission that the system is to grant only if the requesting application is signed with the same certificate that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval. Can be used to limit access to components to only apps signed with the same certificate. protectionLevel="signature or system” – matching certificate with system image But please avoid to use last level as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed

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 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 Allows applications to change network connectivity state BATTERY_STATS Allows an application to collect battery statistics BROADCAST_SMS Allows an application to broadcast an SMS receipt notification levels.html ndroidManifest.xml dangerous dangerous normal Exercise1 signature

Android Permission List
All included in Manifest.permission class latest API version:22 t.permission.html We can find the android permission list in the android documentation online

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 Activity permissions restricts which components can start the associated activity. These permissions are checked within the execution of method such as startActivity() and startActivityForResult() which as you know is a called a activity tries to start another one and if the required permission is missing and then the android will throw a securityexception

service Restricts who can interact with service Checked within execution of Context.startService(), Context.stopService() or Context.bindService() Throw a SecurityException when failed

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 Specifies which data subsets of the parent content provider permission can be granted for. Data subsets are indicated by the path part of a content: URI. (The authority part of the URI identifies the content provider.) Granting permission is a way of enabling clients of the provider that don't normally have permission to access its data to overcome that restriction on a one-time basis. If a content provider's grantUriPermissions attribute is "true", permission can be granted for any the data under the provider's purview. However, if that attribute is "false", permission can be granted only to data subsets that are specified by this element. A provider can contain any number of <grant-uri-permission> elements. Each one can specify only one path (only one of the three possible attributes).

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

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 One common misconception about these permissions is that having the write permission automatically implies the read permission. The logic is that updating data (writing) is a more powerful permission than simply reading it and anyone that can write into a database should also be able to read from it. This is a fallacy, and the Android design, separating read and write permissions, acknowledges that. For example, consider an client app (I really do seem to like this example when discussing component security, don’t I?). In our app, we may implement a Content Provider to store we download from a mail server. A Service may periodically connect to that mail server, download new messages, and put them into our database by writing to that Content Provider. The Service clearly needs the permission to write to the Content Provider, but does it need the permission to read from it? No. In fact, it should not have that permission, as it is not needed for it to do the job it performs. Remember the Principle of Least Privilege: grant the permissions needed to get the job done and no more. With Content Providers, permissions are first verified when you connect to the provider. When you do so, you can connect to it if you have either the read permission or the write permission. If you have neither, the connection request will fail with a thrown SecurityException. Permissions are then checked when you attempt to interact with the Content Provider. Using itsquery() method requires the read permission, while using its insert(), update(), ordelete() methods requires the write permission, as specified in the manifest declaration (DB_READand DB_WRITE in this case). Again, note that having the write permission does not automatically give you the read permission; the two are separate and enforced independently. If you were to call one of these methods without the corresponding permission, the call would not succeed and aSecurityException would be thrown instead.

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>
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 App1’s activity wants to bind app2’service so app2 is checking if app 1 have the required permissions app2 declared

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 Where appropriate, perform access checks using existing permissions. If you must create a new permission, consider whether you can accomplish your task with a "signature" protection level. Signature permissions are transparent to the user and only allow access by applications signed by the same developer as application performing the permission check. If you create a permission with the "dangerous" protection level, there are a number of complexities that you need to consider: The permission must have a string that concisely expresses to a user the security decision they will be required to make. The permission string must be localized to many different languages. Users may choose not to install an application because a permission is confusing or perceived as risky. Applications may request the permission when the creator of the permission has not been installed. Each of these poses a significant non-technical challenge for you as the developer while also confusing your users, which is why we discourage the use of the "dangerous" permission level.

Minimize requested permissions
Users don’t like when your app requests too many permissions… CAMERA MESSAGES/CONTACT ACCESS_FINE_LOCATION

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 Extract permissions as features for each .apk file Use machine learning algorithm to classify samples 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 Over 97% is android malware

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

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 READ_SMS 12 RECEIVE_SMS ∧ SEND_SMS 30 READ_PHONE_STATE ∧ INTERNET 20 GET_ACCOUNTS ∧ INTERNET READ_LOGS ∧ INTERNET 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)
SEND_SMS, RECEIVE_SMS SYSTEM_ALERT_WINDOW READ_HISTROY_BOOKMARKS WRITE_HISTROY_BOOKMARKS READ_CONTACTS, WRITE_CONTACTS, READ_CALENDAR, WRITE_CALENDAR CALL_PHONE READ_LOGS ACCESS_FINE_LOCATION GET_TASKS RECEIVE_BOOT_COMPLETED CHANGE_WIFI_STATE Here’s the list of top 10 bad permissions hope next time if you are trying to install app you can see the list first and see if there is sensitive permissions.

Thank you for your time!

Android Permission System

Similar presentations

Presentation on theme: "Android Permission System"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Android Permission System

Similar presentations

Presentation on theme: "Android Permission System"— Presentation transcript:

Similar presentations

About project

Feedback