Android Security Model

Android Security Model

The Android security model is primarily based on a sandbox and

permission mechanism. Each application is running in a specific Dalvik
virtual machine with a unique user ID assigned to it, which means the
application code runs in isolation from the code of all others applications. As
a consequence, one application has not granted access to other applications’
files.
Android application has been signed with a certificate with a private
key Know the owner of the application is unique. This allows the author of
The application will be identified if needed. When an application is installed
in The phone is assigned a user ID, thus avoiding it from affecting it Other
applications by creating a sandbox for it. This user ID is permanent on which
devices and applications with the same user ID are allowed to run in a single
process. This is a way to ensure that a malicious application has Can not
access / compromise the data of the genuine application.
 It is mandatory for an application to list all the resources it will
Access during installation. Terms are required of an application, in The
installation process should be user-based or interactive Check with the
signature of the application.

Android thread
• Leaking information to logs.
• Sdcard use
• Unprotected Broadcast receivers.
• Intent injection Attacks.
• Wi-fi sniffing
1. Declaring and Using Permissions
• The purpose of a permission is to protect the privacy of an Android
user. Android apps must request permission to access sensitive user
data (such as contacts and SMS), as well as certain system features
(such as camera and internet).
• Depending on the feature, the system might grant the permission
automatically or might prompt the user to approve the request.
• A central design point of the Android security architecture is that no
app, by default, has permission to perform any operations that would
adversely impact other apps, the operating system, or the user. This
includes reading or writing the user's private data (such as contacts or
emails), reading or writing another app's files, performing network
access, keeping the device awake and so on.
• Permission Approval
• Request Prompts for dangerous permissions.
• Runtime requests
• Request prompt to access sensitive user information.
• Permissions for optional Hardware features.
• Permmision Enforcement.
• Activity permission enforcement
• Service permission enforcement
• Broadcast permission enforcement
• Content provide permission enforcement
• URI Permissions.
• Other permission enforcement
• Protection Level
 Permissions are divided into several protection levels. The
protection level affects whether runtime permission requests are
required. There are three protection levels that affect third-party apps:
normal, signature, and dangerous permissions.
1. Normal permissions cover areas where your app needs to access
data or resources outside the app’s sandbox, but where there’s very little
risk to the user’s privacy or the operation of other apps. For example,
permission to set the time zone is a normal permission. If an app
declares in its manifest that it needs a normal permission, the system
automatically grants the app that permission at install time. The system
doesn’t prompt the user to grant normal permissions, and users cannot
revoke these permissions.
2. Signature permissions: The system grants these app permissions at
install time, but only when the app that attempts to use permission is
signed by the same certificate as the app that defines the permission.
3. Dangerous permissions
• Dangerous permissions cover areas where the app wants data or
resources that involve the user’s private information, or could
potentially affect the user’s stored data or the operation of other apps.
• For example, the ability to read the user’s contacts is a dangerous
permission. If an app declares that it needs a dangerous permission, the
user has to explicitly grant the permission to the app.
• Until the user approves the permission, your app cannot provide
functionality that depends on that permission. To use a dangerous
permission, your app must prompt the user to grant permission at
runtime. For more details about how the user is prompted, see Request
prompt for dangerous permission.
Special Permissions.
• There are a couple of permissions that don't behave like normal and
dangerous permissions. SYSTEM ALERT_WINDOW and
WRITE_SETTINGS are particularly sensitive, so most apps should
not use them. If an app needs one of these permissions, it must
declare the permission in the manifest, and send an intent requesting
the user's authorization. The system responds to the intent by
showing a detailed management screen to the user.
• For details on how to request these permissions, see the SYSTEM
ALERT_WINDOW and WRITE_SETTINGS reference entries.
• All permissions provided by the Android system can be found at
Manifest.permission.
Permission Groups
• Permissions are organized into groups related to a device's capabilities
or features. Under this system, permission requests are handled at the
group level and a single permission group corresponds to several
permission declarations in the app manifest.
• For example, the SMS group includes both the READ_SMS and the
RECEIVE_SMS declarations. Grouping permissions in this way
enables the user to make more meaningful and informed choices,
without being overwhelmed by complex and technical permission
requests.
Fig. Permission group
2. Using Custom Permission

• Apps can define their own custom permissions and request custom
permissions from other apps by defining elements. To enforce your
own permissions, you must first declare them in your
AndroidManifest.xml using one or more elements.
• This document describes how app developers can use the security
features provided by Android to define their own permissions. By
defining custom permissions, an app can share its resources and
capabilities with other apps.
• Android is a privilege-separated operating system, in which each app
runs with a distinct system identity (Linux user ID and group ID).
Parts of the system are also separated into distinct identities. Linux
thereby isolates apps from each other and from the system.
• Apps can expose their functionality to other apps by defining
permissions which those other apps can request. They can also define
permissions which are automatically made available to any other apps
which are signed with the same certificate.

App Signing

• All APKs must be signed with a certificate whose private key is held
by their developer. This certificate identifies the author of the app.
• The purpose of certificates in Android is to distinguish app authors.
This allows the system to grant deny apps access to signature-level
permissions and to grant or deny an app's request to be giventhe same
Linux identity as another app.
User IDs and File access
• At install time, Android gives each package a distinct Linux user ID.
The identity remains constant for the duration of the package's life on
that device.
• On a different device, the same package may have a different UID;
what matters is that each package has a distinct UID on a given
device.
• Because security enforcement happens at the process level, the code
of any two packages cannot has a distinct UID Don a given
device.normally run in the same process, since they need to run as
different Linux users.
• We can use the sharedUserid attribute in the AndroidManifest.xml's
manifest tag of each package to have them assigned the same user ID.
By doing this, for purposes of security the two packages are then
treated as being the same app, with the same user I and file
permissions.
• Note that in order to retain security, only two apps signed with the
same signature (and requesting the same sharedUserId) will be given
the same user ID.
• Any data stored by an app will be assigned that app's user ID, and not
normally accessible to other packages.
Defining and enforcing permissions.
• To enforce our own permissions, we must first declare them in our
AndroidManifest.xml using one or more <permission> elements.
• For example, an app that wants to control who can start one of its
activities could declare a permission for this operation as follows:
• The protectionLevel attribute is required, telling the system how the
user is to be informed of apps requiring the permission, or who is
allowed to hold that permission, as described in the linked
documentation.
• The android:permission Group attribute is optional and only used to
help the system display permissions to the user.
• In most cases we should set this to a standard system group (listed in
android. Manifest.permission_group), although we can define a group
ourself. It is preferable to use an existing group, as this simplifies the
permission UI shown to the user.
• We need to supply both a label and description for the permission.
These are string resources that the user can when they are viewing a
list of permissions (android:label) or details on a single permission
(android:description).
• The label should be short; a few words describing the key piece of
functionality the permission is protecting. The description should be a
couple of sentences describing what the permission allows a holder to
do.
• Our convention is a two-sentence description: the first sentence
describes the permission, and the second sentence warns the user of
the type of things that can go wrong if an app is granted the
permission.
• Here, is an example of a label and description for the CALL PHONE
permission:
<stringname="permlab_callPhone">directly call phone
numbers</string>
<stringname="permdesc_callPhone">Allows the app to callphone
numbers without our intervention. Malicious apps may cause
unexpected calls on our phone bill. Note that this does notallow the app
to call emergency numbers.</string>
Defining and enforcing permissions.
• As shown in the previous section, we can use the android.permission
Group attribute to system describe permissions to the user.
• In most cases we will want to set this to a standard system group
(listed in android.Manifest.permission_group), but we can also define
our own group with<permission-group>.
• In The <permission-group> element does not specify the permissions
that belong to the group, but itgives the group a name.
• We can place a permission in the group by assigning the group name
to the <permission> element's permission Group attribute.
• The <permission-tree> element declares a namespace for a group of
permissions that are defined in code.
Create a Permission Group

• As shown in the previous section, we can use the android.permission

Group attribute to help the system describe permissions to the user.
• In most cases we will want to set this to a standard system group(listed
in android.Manifest.permission_group),but we can also define our
own group with <permission-group>
• The <permission-group> element defines a label for a set of
permissions-both those declared in the manifest with <permission>
elements and those declared elsewhere. This affects only how the
permissions are grouped when presented to the user.
• The <permission-group> element does not specify the permissions that
belong to the group, but it gives the group a name.
• We can place a permission in the group by assigning the group name
to the <permission> element's permission Group attribute.
• The <permission-tree> element declares a namespace for a group of
permissions that are defined in code.
Custom Permission Recommendations

• Apps can define their own custom permissions and request custom
permissions from other apps by defining <uses-permission> elements.
However, we should carefully assess whether it is necessary for our app
to do so.
• If we are designing a suite of apps that expose functionality to one
another, try to design the apps so that each permission is defined only
once.
• We must do this if the apps are not all signed with the same certificate.
Even if the apps are all signed with the same certificate, it's a best
practice to define each permission once only.
• If the functionality is only available to apps signed with the same
signature as the providing app, we may be able to avoid defining
custom permissions by using signature checks. When one of our apps
makes a request of another of our apps, the second app can verify that
both apps are signed with the same certificate before complying with
the request.