Android Overview Download

Transcript
CSF665 – Advanced Operating Systems
高等作業系統
Android
吳俊興
國立高雄大學 資訊工程學系
Outline
•System Overview
– Applications, Development, Platform
•Android System Security
– Kernel and System Level Security
– Security Enhancements
•Android Application Security
2
System Overview
• Android
– Unveiled by Google along with the founding of Open Handset
Alliance to advance open standards for mobile devices
• Early SDK was released on 12 November 2007
– iPhone firstly announced on January 9 2007
• Google acquired Android Inc. on August 17, 2005
• The first Android-powered phone was sold in October 2008
– Designed primarily for touchscreen mobile devices such as
smartphones and tablet computers
• As of Q3 2012, there were 500 million devices activated and 1.3 million
activations per day
– Building on open-source Linux
• Android code released as open source, under the Apache License
3
Android Applications
• Applications are usually developed in the Java language using
the Android Software Development Kit
– Native Development Kit for applications or extensions in C or C++
– Installed from a single file with the .apk file extension
• Android applications run in a sandbox
– An isolated area of the OS that does not have access to the rest of the
system's resources, unless access permissions are granted by the user
when the application is installed
• However, applications routinely requesting unnecessary permissions, reducing
its effectiveness
• The complexity of inter-application communication implies Android may have
opportunities to run unauthorized code
• Two primary sources for applications
– Pre-Installed Applications
– User-Installed Applications
• Either through a store such as Google Play or the Amazon Appstore, or by
• Downloading and installing the application's APK file from a third-party site
4
Android Development
• Android consists of
– A kernel based on the Linux kernel 2.6 and Linux Kernel 3.x (Android 4.0
onwards)
• Does not have a native X Window System nor does it support the full set of
standard GNU libraries
• a power management feature called wakelocks
• The flash storage is split into several partitions, such as "/system" for the
operating system itself and "/data" for user data and app installations
• Android device owners are not given root access
– With middleware, libraries and APIs written in C and
• Dalvik virtual machine with just-in-time compilation to run Dalvik dex-code
(Dalvik Executable), which is usually translated from Java bytecode
– Application software running on an application framework which includes
Java-compatible libraries based on Apache Harmony
– The main hardware platform for Android is the ARM architecture
5
Android Platform Building Blocks
• Device Hardware
– Including smart phones, tablets, and set-top-boxes
– Processor-agnostic, but taking advantage of some hardware-specific
security capabilities such as ARM v6 eXecute-Never
• Android Operating System
– The core operating system is built on top of the Linux kernel
– All device resources, like camera functions, GPS data, Bluetooth functions,
telephony functions, network connections, etc. are accessed through the
operating system
• Android Application Runtime
– Most often written in the Java programming language and run in the
Dalvik virtual machine
– But core Android services and applications are native applications or
include native libraries
– Both Dalvik and native applications run within the same security
environment, contained within the Application Sandbox
• Applications get a dedicated part of the filesystem in which they can write private
data, including databases and raw files
6
Architecture Diagram
7
Main Android Application Building Blocks
• AndroidManifest.xml: the control file that
– Tells the system what to do with all the top-level components
in an application
• specifically activities, services, broadcast receivers, and content
providers
– Also specifies which permissions are required
• Activities: An Activity is the code for a single, userfocused task
– Usually includes displaying a UI to the user
• some Activities never display UIs
– Typically, one of the application's Activities is the entry point
to an application
8
Main Android Application Building Blocks (cont.)
• Services: A Service is a body of code that runs in the
background
– It can run in its own process, or in the context of another application's
process
– Other components "bind" to a Service and invoke methods on it via
remote procedure calls
– An example of a Service is a media player
• even when the user quits the media-selection UI, the user probably still intends
for music to keep playing
• A Service keeps the music going even when the UI has completed
• Broadcast Receiver
– A BroadcastReceiver is an object that is instantiated when an IPC
mechanism known as an Intent is issued by the operating system or
another application
– For example, an application may register a receiver for the low battery
message and change its behavior based on that information
9
Android Versions
Version
4.1.x Jelly Bean
4.0.x Ice Cream Sandwich
3.x.x Honeycomb
2.3.x Gingerbread
2.2 Froyo
2.0, 2.1 Eclair
1.6 Donut
1.5 Cupcake
Release date
July 9, 2012
October 19, 2011
February 22, 2011
December 6, 2010
May 20, 2010
October 26, 2009
September 15, 2009
April 30, 2009
API level
16
14-15
11-13
9-10
8
7
4
3
10
Android Security Overview
• Security objectives
– Protect user data
– Protect system resources (including the network)
– Provide application isolation
• Key security features
– Linux security
• Secure interprocess communication
– Mandatory application sandbox for all applications
• Exception of a small amount of Android OS code running as root, all
code above the Linux Kernel is restricted by the Application Sandbox
– Application signing
– Application-defined and user-granted permissions
11
Kernel and System Level Security
• Linux fundamental security features
– Prevents user A from reading user B's files
– Ensures that user A does not exhaust user B's memory
– Ensures that user A does not exhaust user B's CPU
resources
– Ensures that user A does not exhaust user B's devices (e.g.
telephony, GPS, bluetooth)
• Android security features
– A user-based permissions model
– Process isolation
– Extensible mechanism for secure IPC
– The ability to remove unnecessary and potentially insecure
parts of the kernel
12
Android Security Enhancements
• Application Sandbox
• System Partition and Safe Mode
• Filesystem Permissions
• Filesystem Encryption
• Device Administration
• Password Protection
• Memory Management Security Enhancements
13
Application Sandbox
• Assign a unique user ID (UID) to each Android
application
– runs it as that user in a separate process
• A kernel-level Application Sandbox
– The kernel enforces security between applications and the
system at the process level through standard Linux facilities,
such as user and group IDs that are assigned to applications
– By default, applications cannot interact with each other and
applications have limited access to the operating system
• Explicit user-granted permissions required
14
System Partition and Safe Mode
• System Partition
– Set to read-only
– Containing Android's kernel as well as the operating
system libraries, application runtime, application
framework, and applications
• Safe Mode
• When a user boots the device into Safe Mode, only core Android
applications are available
15
Filesystem: Permissions and Encryption
• Filesystem Permissions
– Each application runs as its own user
– Files created by one application cannot be read or altered by another
application unless the developer explicitly exposes files to other
applications
• Filesystem Encryption
– Android 3.0 and later provides full filesystem encryption
• All user data can be encrypted in the kernel using the dmcrypt implementation of
AES128 with CBC and ESSIV:SHA256
– Filesystem encryption requires the use of a user password
• The encryption key is protected by AES128
• A key derived from the user password, preventing unauthorized access to
stored data without the user device password
• The password is combined with a random salt and hashed repeatedly with
SHA1 using the standard PBKDF2 algorithm
http://source.android.com/tech/encryption/android_crypto_implementation.html
16
Device Administration and Password Protection
• Device Administration API
– Android 2.2 and later provide device administration features at the system
level
– A system administrator writes the device admin application to be installed
on users’ devices
• Administrators can enforce password policies — including alphanumeric
passwords or numeric PINs — across devices
• Administrators can also remotely wipe (that is, restore factory defaults on) lost or
stolen handsets
https://developer.android.com/guide/topics/admin/device-admin.html
• Password Protection
– Can be configured to verify a user-supplied password prior to providing
access to a device
• This password protects the cryptographic key for full filesystem encryption
– Use of a password and/or password complexity rules can be required by a
device administrator
17
Memory Management Security Enhancements
•Android 1.5+
– ProPolice to prevent stack buffer overruns (-fstack-protector)
– safe_iop to reduce integer overflows
– Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and to
prevent chunk consolidation attacks. Chunk consolidation attacks are a common
way to exploit heap corruption.
– OpenBSD calloc to prevent integer overflows during memory allocation
•Android 2.3+
– Format string vulnerability protections (-Wformat-security -Werror=format-security)
– Hardware-based No eXecute (NX) to prevent code execution on the stack and heap
– Linux mmap_min_addr to mitigate null pointer dereference privilege escalation
(further enhanced in Android 4.1)
•Android 4.0+
– Address Space Layout Randomization (ASLR) to randomize key locations in
memory
•Android 4.1+
–
–
–
–
PIE (Position Independent Executable) support
Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)
dmesg_restrict enabled (avoid leaking kernel addresses)
kptr_restrict enabled (avoid leaking kernel addresses)
18
Android Application Security
• Protected API: only accessible through the OS
– Camera functions
Location data (GPS)
– Bluetooth functions Telephony functions
– SMS/MMS functions Network/data connections
• Steps
1. An application defines the capabilities it needs in its manifest
2. When preparing to install an application, the system displays a dialog to the user
that indicates the permissions requested and asks whether to install
3. If continues, the user has granted all of the requested permissions
• The user must grant or deny all of the requested permissions as a block
• Applications included in the core OS or bundled by an OEM do not request permissions
from the user
4. Once granted, the permissions are applied to the application as long as it is
installed
• Some device capabilities, such as the ability to send SMS broadcast intents,
that are not available to third-party applications
– That may be used by applications pre-installed by the OEM
– These permissions use the signatureOrSystem permission
19
Interprocess Communication
• Processes can communicate using traditional UNIX-type
mechanisms
– For examples, filesystem, local sockets, or signals
– The Linux permissions still apply
• New IPC mechanisms
– Binder: A lightweight capability-based RPC mechanism designed for high
performance when performing in-process and cross-process calls
• Implemented using a custom Linux driver
– Services: provide interfaces directly accessible using binder
– Intents: An Intent is a simple message object that represents an
"intention" to do something. For example, to display a web page
• An app expresses its "Intent" by creating an Intent instance to view the URL
• The system locates some other piece of code (in this case, the Browser) that
knows how to handle that Intent, and runs it
– ContentProviders: A ContentProvider is a data storehouse that provides
access to data on the device
• An application can access data that other applications have exposed via a
ContentProvider, and
• An application can define its own ContentProviders to expose data of its own 20
Cost-Sensitive APIs
• A cost sensitive API is any function that might generate a cost
for the user or the network
–
–
–
–
–
Telephony
SMS/MMS
Network/Data
In-App Billing
NFC Access
• Placed in the list of protected APIs controlled by the OS
• The user will have to grant explicit permission to third-party
applications requesting use of cost sensitive APIs
21
SIM Card and Sensitive User Data
• SIM Card Access
– Low level access to SIM card not available to third-party apps
– Cannot access AT commands
• Sensitive User Data Accessed Only by Protected APIs
– Personal information
– Sensitive input devices: i.e. GPS, camera
– Device metadata: i.e. system logs, browser history, phone number, or
hardware / network identification information
22
Digital Rights Management
• Two architectural layers
– A DRM framework API, which is exposed to applications through the
Android application framework and runs through the Dalvik VM for
standard applications
– A native code DRM manager, which implements the DRM framework and
exposes an interface for DRM plug-ins (agents) to handle rights
management and decryption for various DRM schemes
23
References
• http://en.wikipedia.org/wiki/Android_(operating_system)
• http://source.android.com/tech/security/
• http://developer.android.com/
24