资源描述
Understanding Android Security-WILLIAM ENCK MACHIGAR ONGRANG,McD ANIEL Pennsylvania State UniversityThe next generation of open operating systems wont be on desktops or mainframes but on the small mobile devices we carry every day. The openness of these new environments will lead to new applications and markets and will enable greater integration with existing online services. However, as the importance of the data and services our cell phones support increases, so too do the opportunities for vulnerability. Its essential that this next generation of platforms provides a comprehensive and usable security infrastructure.Developed by the Open Handset Alliance (visibly led by Google), Android is a widely anticipated open source operating system for mobile devices that provides a base operating system, an application middleware layer, a Java software development kit (SDK), and a collection of system applications. Although the Android SDK has been available since late 2007, the first publicly available Android ready “G1” phone debuted in late October 2008. Since then, Androids growth has been phenomenal: T-Mobiles G1 manufacturer HTC estimates shipment volumes of more than 1 million phones by the end of 2008, and industry insiders expect public adoption to increase steeply in 2009. Many other cell phone providers have either promised or plan to support it in the near future.A large community of developers has organized around Android, and many new products and applications are now available for it. One of Androids chief selling points is that it lets developers seamlessly extend online services to phones. The most visible example of this feature is, unsurprisingly, the tight integration of Googles Gmail, Calendar, and Contacts Web applications with system utilities. Android users simply supply a username and password, and their phones automatically synchronize with Google services. Other vendors are rapidly adapting their existing instant messaging, social networks, and gaming services to Android, and many enterprises are looking for ways to integrate their own internal operations (such as inventory management, purchasing, receiving, and so forth) into it as well.Traditional desktop and server operating systems have struggled to securely integrate such personal and business applications and services on a single platform. Although doing so on a mobile platform such as Android remains nontrivial, many researchers hope it provides a clean slate devoid of the complications that legacy software can cause. Android doesnt officially support applications developed for other platforms: applications execute on top of a Java middleware layer running on an embedded Linux kernel, so developers wishing to port their application to Android must use its custom user interface environment. Additionally, Android restricts application interaction to its special APIs by running each application as its own user identity. Although this controlled interaction has several beneficial security features, our experiences developing Android applications have revealed that designing secure applications isnt always straightforward. Android uses a simple permission label assignment model to restrict access to resources and other applications, but for reasons of necessity and convenience, its designers have added several potentially confusing refinements as the system has evolved.This article attempts to unmask the complexity of Android security and note some possible development pitfalls that occur when defining an applications security. We conclude by attempting to draw some lessons and identify opportunities for future enhancements that should aid in clarity and correctness. Android ApplicationsThe Android application framework forces a structure on developers. It doesnt have a main()function or single entry point for executioninstead, developers must design applications in terms of components. Example ApplicationWe developed a pair of applications to help describe how Android applications operate. Interested readers can download the source code from our Web site (http:/siis.cse.psu.edu/android_sec_tutorial.html).Lets consider a location-sensitive social networking application for mobile phones in which users can discover their friends locations. We split the functionality into two applications: one for tracking friends and one for viewing them. As Figure 1 shows, the FriendTracker application consists of components specific to tracking friend locations (for example, via a Web service), storing geographic coordinates, and sharing those coordinates with other applications. The user then uses the FriendViewer application to retrieve the stored geographic coordinates and view friends on a map.Both applications contain multiple components for performing their respective tasks; the components themselves are classified by their component types. An Android developer chooses from predefined component types depending on the components purpose (such as interfacing with a user or storing data).Component TypesAndroid defines four component types:Activity components define an applications user interface. Typically, an application developer defines one activity per “screen.” Activities start each other, possibly passing and returning values. Only one activity on the system has keyboard and processing focus at a time; all others are suspended.Service components perform background processing. When an activity needs to perform some operation that must continue after the user interface disappears (such as download a file or play music), it commonly starts a service specifically designed for that action. The developer can also use services as application-specific daemons, possibly starting on boot. Services often define an interface for Remote Procedure Call (RPC) that other system components can use to send commands and retrieve data, as well as register callbacks. Content provider components store and share data using a relational database interface. Each content provider has an associated “authority” describing the content it contains. Other components use the authority name as a handle to perform SQL queries (such as SELECT, INSERT, or DELETE) to read and write content. Although content providers typically store values in database records, data retrieval is implementation specificfor example, files are also shared through content provider interfaces.Broadcast receiver components act as mailboxes for messages from other applications. Commonly, application code broadcasts messages to an implicit destination. Broadcast receivers thus subscribe to such destinations to receive the messages sent to it. Application code can also address a broadcast receiver explicitly by including the namespace assigned to its containing application. Figure 1 shows the FriendTracker and FriendViewer applications containing the different component types. The developer specifies components using a manifest file. There are no restrictions on the number of components an application defines for each type, but as a convention, one component has the same name as the application. Frequently, this is an activity, as in the FriendViewer application. This activity usually indicates the primary activity that the system application launcher uses to start the user interface; however, the specific activity chosen on launch is marked by meta information in the manifest.In the FriendTracker application, for example, the FriendTrackerControl activity is marked as the main user interface entry point. In this case, we reserved the name “FriendTracker” for the service component performing the core application logic.The FriendTracker application contains each of the four component types. The FriendTracker service polls an external service to discover friends locations. In our example code, we generate locations randomly, but extending the component to interface with a Web service is straightforward. The FriendProvider content provider maintains the most recent geographic coordinates for friends, the FriendTracker Control activity defines a user interface for starting and stopping the tracking functionality, and the BootReceiver broadcast receiver obtains a notification from the system once it boots (the application uses this to automatically start the FriendTracker service).The FriendViewer application is primarily concerned with showing information about friends locations. The FriendViewer activity lists all friends and their geographic coordinates, and the FriendMap activity displays them on a map. The FriendReceiver broadcast receiver waits for messages that indicate the physical phone is near a particular friend and displays a message to the user upon such an event. Although we could have placed these components within the FriendTracker application, we created a separate application to demonstrate cross-application communication. Additionally, by separating the tracking and user interface logic, we can create alternative user interfaces with different displays and featuresthat is, many applications can reuse the logic performed in FriendTracker.Component InteractionThe primary mechanism for component interaction is an intent, which is simply a message object containing a destination component address and data. The Android API defines methods that accept intents and uses that information to start activities (s t a r t A c t i v i t y ( I n t e n t ), start services (startService(Intent), and (sendBroadcast(Intent). The invocation of these methods tells the Android framework to begin executing code in the target application. This process of intercomponent communication is known as an action. Simply put, an intent object defines the “intent” to perform an “action.”One of Androids most powerful features is the flexibility allowed by its intent-addressing mechanism. Although developers can uniquely address a target component using its applications namespace, they can also specify an implicit name. In the latter case, the system determines the best component for an action by considering the set of installed applications and user choices. The implicit name is called an action string because it specifies the type of requested actionfor example, if the “VIEW” action string is specified in an intent with data fields pointing to an image file, the system will direct the intent to the preferred image viewer. Developers also use action strings to broadcast a message to a group of broadcast receivers. On the receiving end, developers use an intent filter to subscribe to specific action strings. Android includes additional destination resolution rules, but action strings with optional data types are the most common.Figure 2 shows the interaction between components in the FriendTracker and FriendViewer applications and with components in applications defined as part of the base Android distribution. In each case, one component initiates communication with another. For simplicity, we call this inter component communication (ICC). In many ways, ICC is analogous to inter-process communication (IPC) in Unix-based systems. To the developer, ICC functions identically regardless of whether the target is in the same or a different application, with the exception of the security rules.The available ICC actions depend on the target component. Each component type supports interaction specific to its typefor example, when FriendViewer starts FriendMap, the FriendMap activity appears on the screen. Service components support start, stop, and bind actions, so the FriendTrackerControl activity, for instance, can start and stop the FriendTracker service that runs in the background. The bind action establishes a connection between components, allowing the initiator to execute RPCs defined by the service. In our example, FriendTracker binds to the location manager in the system server. Once bound, FriendTracker invokes methods to register a callback that provides updates on the phones location. Note that if a service is currently bound, an explicit “stop” action wont terminate the service until all bound connections are released.Broadcast receiver and content provider components have unique forms of interaction. ICC targeted at a broadcast receiver occurs as an intent sent (broadcast) either explicitly to the component or, more commonly, to an action string the component subscribes to. For example, FriendReceiver subscribes to the developer-defined “FRIEND_NEAR” action string. FriendTracker broadcasts an intent to this action string when it determines that the phone is near a friend; the system then starts FriendReceiver and displays a message to the user.Content providers dont use intentsrather, theyre addressed via an authority string embedded in a special content URI of the form c o n t e n t : / / /. H e r e , indicates a table in the content provider, and optionally specifies a record in that table. Components use this URI to perform a SQL query on a content provider, optionally including WHERE conditions via the query API.Security EnforcementAs Figure 3 shows, Android protects applications and data through a combination of two enforcement mechanisms, one at the system level and the other at the ICC level. ICC mediation defines the core security framework and is this articles focus, but it builds on the guarantees provided by the underlying Linux system.In the general case, each application runs as a unique user identity, which lets Android limit the potential damage of programming flaws. For example, the Web browser vulnerability discovered recently after the official release of T-Mobile G1 phones only affected the Web browser itself ( Because of this design choice, the exploit couldnt affect other applications or the system. A similar vulnerability in Apples iPhone gave way to the first “jail breaking” technique, which let users replace parts of the underlying system, but would also have enabled a network-based adversary to exploit this flaw (http:/securitye valuators . com/content/case-studies/iphone/index.jsp).ICC isnt limited by user and process boundaries. In fact, all ICC occurs via an I/O control command on a special device node, /dev/binder. Because the file must be world readable and writable for proper operation, the Linux system has no way of mediating ICC. Although user separation is straightforward and easily understood, controlling ICC is much more subtle and warrants careful consideration.As the central point of security enforcement, the Android middleware mediates all ICC establishment by reasoning about labels assigned to applications and components. A reference monitor1 provides mandatory access control (MAC) enforcement of how applications access components. In its simplest form, access to each component is restricted by assigning it an access permission label; this text string need not be unique. Developers assign applications collections of permission labels. When a component initiates ICC, the reference monitor looks at the permission labels assigned to its containing application andif the target components access permission label is in that collectionallows ICC establishment to proceed. If the label isnt in the collection, establishment is denied even if the components are in the same application. Figure 4 depicts this logic.The developer assigns permission labels via the XML manifest file that accompanies every application package. In doing so, the developer defines the applications security policythat is, assigning permission labels to an application specifies its protection domain, whereas assigning permissions to the components in an application specifies an access policy to protect its resources. Because Androids policy enforcement is mandatory, as opposed to discretionary, all permission labels are set at install time and cant change until the application is reinstalled. However, despite its MAC properties, Androids permission label model only restricts access to components and doesnt currently provide information flow guarantees, such as in domain type enforcement.Security RefinementsAndroids security framework is based on the label-oriented ICC mediation described thus far, but our description is incomplete. Partially out of necessity and partially for convenience, the Google developers who designed Android incorporated several refinements to the basic security model, some of which have subtle side effects and make its overall security difficult to understand. Public vs. Private ComponentsApplications often contain components that another application should never accessfor example, an activity designed to return a user-entered password could be started maliciously. Instead of defining an access permission, the developer could make a component private by either explicitly setting the exported attribute to false in the manifest file or letting Android infer if the component should be private from other attributes in its manifest definition.Private components simplify security specification. By making a component private, the developer doesnt need to worry which permission label to assign it or how another application might acquire that label. Any application can access components that arent explicitly assigned an access permission, so the addition of private components and inference rules (introduced in the v0.9r1 SDK release, August 2008) significantly reduces the attack surface for many applications. However, the developer must be careful when allowing Android to determine if a component is private. Security-aware developers should always explicitly define the exported attribute for components intended to be private.Implicitly Open ComponentsDevelopers frequently define intent filters on activities to indicate that they can handle certain types of action/data combinations. Recall the example of how the system finds an image viewer when an intent specifying the VIEW action and an image reference is passed to the “start activity” API. In this case, the caller cant know beforehand (much less at development time) what access permission is required. The developer of the target activity can permit such functionality by not assigning an access permission to itthat is, if a public component doesnt explicitly have an access permission listed in its manifest definition, Android permits any application to access it.Although this default policy specification enables functionality and ease of development, it can lead to poor security practices and is contrary to Saltzer and Schroeders principle of fail-safe defaults.4Referring back to our example FriendViewer application, if the FriendReceiver broadcast receiver isnt assigned an access permission, any unprivileged installed application can forge a FRIEND_NEAR message, which represents a significant security concern for applications making decisions based on information passed via the intent. As a general practice, security aware developers should always assign access permissions to public componentsin fact, they should have an explicit reason for not assigning one. All inputs should be scrutinized under these conditions.References1. J.P. Anderson, Computer Security Technology Planning Study, tech. report ESD-TR-73-51, Mitre, Oct. 1972.2. M.A. Harrison, W.L. Ruzzo, and J.D. Ullman, “Protection in Operating Systems,” Comm. ACM, vol. 19, no. 8外 文 译 文下一代开放式操作系统不会是在电脑或大型主机上而是在我们可以每天携带的小手机上。这些新环境的开放性会带来新的应用和市场，同时会促进现存网络设备的更大程度集成。但是，在我们手机所能支持的设备和数据的重要性不断提升的情况下，出现问题和故障的几率也在不断提升。所以，下一代平台必须要能提供一个综合且有用的安全底层架构支撑。由手机开放联盟（明显由google领导的）开发的android，是一个为手机设备制作的被广为期待的开源式操作系统。他提供了一个基础运行系统，一个应用中间层，一个java软件开发包（SDK
展开阅读全文