Android Security Security Philosophy Humans have difficulty - PowerPoint PPT Presentation

Android Security

Security Philosophy • Humans have difficulty understanding risk • Safer to assume that – Most developers do not understand security – Most users do not understand security • Security philosophy cornerstones – Need to prevent security breaches from occurring – Need to minimize the impact of a security breach – Need to detect vulnerabilities and security breaches – Need to react to vulnerabilities and security breaches swiftly

Android Security Architecture Security goals • Protect user data • Protect system resources (hardware, software) • Provide application isolation Foundations of Android Security Application Isolation and Permission Requirement • Mandatory application sandbox for all applications • Secure inter-process communication (IPC) • System-built and user-defined permissions • Application signing

Android Software Stack

Android software stack • Each component assumes all supporting components below are properly secured. • All code above the Linux Kernel is restricted by the Application Sandbox • Linux kernel is responsible for app sandboxing • Sandboxing application – mutually distrusting principals – Default access to only its own data • The app Sandbox apps can talk to other apps only via Intents (message) , IPC, and ContentProvider and ContentResolver • To escape sandbox, permissions is needed

1. Security at the Linux kernel • A user-based permissions model • Process isolation: Each application has its sandbox based on separation of processes: to protect user resources from each another; each runs in its own Linux process to secure Inter- Process communication (IPC) Ex: – Prevents user A from reading user B's files – Ensures that user A does not access user B's CPU, memory resources – Ensures that user A does not access user B's devices (e.g. telephony, GPS, Bluetooth)

Application Sandbox • The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process. • The developer of that application has ensured that it will not do anything the phone’s user didn’t intend • Application A is not allowed to do something malicious like read application B's data or dial the phone without permission. • All libraries, application runtime, and all applications run within the Application Sandbox in the kernel.

Permissions and Encryption • Permissions In Android, each application runs as its own user. Unless the developer explicitly exposes files to other applications, files created by one application cannot be read or altered by another application. • Password Protection Android can require a user-supplied password prior to providing access to a device. In addition to preventing unauthorized use of the device, this password protects the cryptographic key for full filesystem encryption.

Encryption • Encryption Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel The encryption key is protected by using a key derived from the user password, preventing unauthorized access to stored data without the user device password. • For a lost or stolen device, full filesystem encryption on Android devices uses the device password to protect the encryption key, so modifying the bootloader or operating system is not sufficient to access user data without the user’s device password.

2. Android Application Security Application framework • Almost all Android applications are written in the Java and run in the Dalvik virtual machine. Android application deployed in .apk a single file. • Android middleware is base on the Linux kernel. It provides several native libraries and a Dalvik virtual machine (DVM) instead of Java virtual machine (JVM) for its applications’ runtime environment where application isolations is enforced. • The Java written Android middleware provides development APIs and the system service, all basic phone device functionalities

Configurations of Android applications • The AndroidManifest.xml file is the configuration file of the Android application. • It specifies the components in the application and external libraries it uses. • It tells the system what to do with activities, services, broadcast receivers, and content providers in an application. • It declares permissions it requests as well as permissions that are defined to protect its own components. The client must be granted such permission in order to run the application. – Without user’s consent application will not be installed

Android Permission Model • Applications have no permissions by default – Permissions list: Manifest.permission • Applications declare the permissions they require – Android system prompts the user for consent at the time the application is installed – in AndroidManifest.xml, add one or more <uses-permission> tags • e.g., <uses-permission android:name= "android.permission.RECEIVE_SMS" /> – granting permissions in the code

Android Permission Model • Permissions are the core concepts in the Android security to control the access from one application component to another. • All permissions are set at install time and can’t change until the application is reinstalled. • Android’s permission only restricts components to access resources – E.g. an application needs the READ_CONTACTS permission to read the user’s address book • If a public component doesn’t explicitly declare any access permission, Android permits any application to access it.

Component A’s ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application where A is in.

3. Secure coding in Android’s Inter -Application • If Sender does not correctly specify recipient B A – Attacker can intercept the message • If Component does not restrict from whom it can receive messages C – Attacker can inject code

IPC - Intents • Link applications and form the foundation of the message passing system • Are messages containing a recipient and data (optional) • Used for intra- and inter-app communication and system-wide notifications ( system broadcast Intents ) • Are divided into explicit and implicit – Explicit: specifies a definite application – Implicit: specifies a kind or categories • Are delivered to components

IPC - Components • Activities – Started with intents – Can return data – All UI is defined in an activity • Services – Started with intents – Background; no UI – Other components bind to • Allows binder to invoke service’s methods (must be declared in the interface) • Broadcast receivers (3 types) – Work on intents, which may be sent to multiple apps – Background; no UI – Normal – sent to all registered receivers at once – Ordered – sent to receivers in order; any app can halt progression of message; apps can set their own priority level – Sticky – remain accessible after initial delivery; available to be re-broadcast to future (new) receivers • Content providers – Databases addressable by an URI – Used for internal (app’s own) data needs – Can be used to share data between apps

IPC - Components • Activities, Services, and Broadcast Receivers can send/receive Intents • Intents (explicit & implicit) can – Start Activities – Start, stop, and bind Services – Broadcast information to Broadcast Receivers • To receive Intents, component must be declared in the manifest • By default, components can only receive internal Intents

IPC – Exporting Components • Public components can receive Intents from other apps • Is public (exported) if either: – EXPORTED flag is set – At least one Intent filter • Intent can contain – Component name, an action, data, a category, extra data • Intent filter constrains incoming Intents by – Action : a general operation to be performed – Data : specifies the type of data – Category : additional information about the action • No rule against multiple applications specifying the same Intent filter • Intent filters ARE NOT a security mechanism

IPC - Permissions • Caller must have a certain permission • Core system API does – e.g., <uses-permission android:name="android.permission.CALL_PHONE" ></uses-permission> • Can specify a protection level

IPC – Protection Levels • Normal – Granted automatically • Dangerous – Granted during installation. If user does not accept, installation fails. • Signature – Granted only if requesting app is signed by the same developer that defined the permission – Useful for restricting component access to those apps under the control of the same developer • SignatureOrSystem – Granted if meet the Signature requirement OR if installed in the system application folder – Market apps cannot install into the system app folder – Device manufacturers or end-users can manually install into the system app folder