Patent Application
20150150119
An embodiment relates generally to mobile computing devices.
Operating system platforms for mobile computing devices enable the users of such devices to download application programs to their mobile computing devices.
A central design point of the operating system platforms is the security architecture. By default, no application has the permission to perform any operation that would adversely affect other applications or the operating system. Such applications being executed off the same platform of the mobile computing device share resources and data. This is performed by declaring permissions that are needed for execution of the application, but may not be initially allowed by the operating system. As a result, when users of the mobile computing device are downloading a respective application to their mobile computing device, the users are prompted by the operation system as to which permissions will be allowed to execute the application. The user is prompted for consent at the time the application is installed. Such systems have no mechanism for granting permissions at the time the application is executed. Once the user accepts the permission at the high level application permissions, there is no security check for malicious applications that once installed find ways around the operating system to obtain access to system's resources that should be off-limits to the application when launched.
An advantage of an embodiment is the mapping of high-level application permissions to low-level mandatory access control (MAC) policies. High-level application permissions, declared in a file that is part of an application's package and often presented to the user for subsequent approval prior to installation, have been recently adopted on a large class of mobile devised utilizing the operating system platform. The embodiments described herein are applicable to a wide variety of platforms for generating finer-granularity policies based on the permissions requested in a permission file, confining each application's access to resources, hardening the overall system, and improving security.
In an embodiment of the invention contemplates a method is provided for access control of an application feature to resources on a mobile computing device. An application is prepared for installation on the mobile computing device via a processor. An application permission associated with the application is identified. The application permission relates to access of resources of the mobile computing device. Restrictions associated with the application permission are determined. A set of mandatory access control rules are defined for the application permission based on the restrictions. The set of mandatory access control rules and the application permission are combined in a loadable mandatory access control policy module. The loadable mandatory access control policy is stored in a memory of the mobile computing device. The loadable mandatory access control policy module capable of being enforced by an operating system of the mobile computing device.
A method for installing access control on a mobile computing device. A communication is established between a mobile computing device and an application distribution entity. The application distribution entity configured to transmit an application to the mobile computing device upon a request by the mobile computing device. A request is sent by the mobile computing device to the application entity for downloading the application. Application permissions associated with the application are identified, the application permission relating to access resources of the mobile computing device. Restrictions associated with the application permission are determined. A set of mandatory access control rules are defined for the application permission. The set of mandatory access control rules and the application permission are combined in a loadable mandatory access control policy module.
When an application is downloaded to a mobile computing device, the user is prompted with one or more high-level permissions that the user must agree to in order to complete installation of the application. Permissions are security features are mechanisms that enforce restrictions on the specific resources or operations of the mobile computing device that a particular process can perform. An example of permissions is shown in
Once the application is loaded and whenever the application is attempted to be launched, authorization rules are attempted to be enforced by the operating system for determining whether access can take place. However, not all applications installed can be trusted. For example, some applications could be developed by untrusted parties and may contain malicious code that once installed, may have algorithms to go behind the security operations performed by the operating system, or some applications may have potential security flaws of which security risks must be minimized. Therefore, the following technique describes a framework that allows the development and use of low-level mandatory access control (MAC) policies for strengthening security so that only those specific permission granted authorization are granted access. The process operates by mapping the high-level authorized permissions to low-level MAC policies. MAC refers to a type of access control by which the operating system constrains the ability of a subject to access/perform some type of operation on an object or target. In general, a subject relates to a process or thread, whereas objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, etc. Subjects and objects both have a set of security attributes. When a subject attempts to access an object, an authorization rule, enforced by the operating system kernel, examines the security attributes and makes the necessary determination of whether access can be granted. Any operation by a subject on an object will be tested against the set of authorization rules (hereinafter referred to as a MAC policy) to determine if the operation is allowed.
The high-level application permissions that are declared in a file that are part of an application's package and presented to the user for subsequent approval prior to installation of the application generates finer-granularity policies based on the permissions requested in these permission files, thereby confining each application's access to resources, hardening the overall system, and improving its security. This approach further restricts an application's access to the system's resources (e.g., files, network sockets, peripherals, camera, user contacts and data), well beyond that of traditional permission access model, by extending it to use a MAC policy.
The embodiments described herein are for mapping the application permissions to MAC, which results in a significant reduction in the size of the trusted code base. Compared to approaches that operate directly at the MAC policy level, this technique provides the advantage of being able to formulate and manage policies at the application permission level, where the permissions are easier to manage, and enforcing the permissions at a much lower MAC level where the permissions can be more securely enforced. Without this technique described herein, it is only possible to execute one or the other, but not both.
A block diagram for installing an application on a generic platform with any MAC capability is shown in
In block 32, the high level application permissions are broken down into low-level MAC rules during on-line processing. A software mechanism scans a file that contains permissions that the application is requesting (e.g., permissions section in the manifest file). The system via the processor converts each permission in the file to its corresponding MAC rule with the required details (e.g., whether a socket TCP or UDP socket in the case of internet permission). Therefore, MAC rules for defining what the specific permissions relating to communications, ports, devices, and other access details is identified for each permission. This step may require enforcing the appropriate MAC labeling of the processes and/or applications, on which the new rules are to be imposed. This step may also require analysis of the application source code, if provided, or analysis of the binary code if no source code is provided. As an option, high-level permissions language could further be extended to give additional information in the requested permissions that would help the process of mapping them to the MAC rules.
In regards to an application, if little information is known about the application, then a general set of MAC rules may be utilized for a respective permission. That is, the less that is known about an application (e.g., more possibility that it may be from an untrusted source or have the potential to be malicious), then the more constraints that are applied to the permission at the MAC level. If more information is known about the application, such that it is trusted and it is readily understood that accessing information is being used for legitimate reasons, then the permissions may be more broadly granted thereby allowing more freedom for accessing certain features or operations. Having knowledge of an application may be performed manually by a programmer generating the manifest file, or may be performed autonomously through software using other mapping techniques.
In block 33, the low level MAC rule is combined into a dynamically loadable policy module. An example is a mapping of an internet high-level permission in the manifest.xml file to a respective SELinux MAC rule identifies that the application may create a socket and specifies (in the MAC rule) which type of SCKET, TCP or UDP, and the allowed port that may be used. Each one of the high-level permissions are translated to low level MAC rules, and each of the translated permissions are bundled into one loadable policy module (e.g., a SELinux policy module that can be enabled in the SELinux policy when the application is executed).
In step 34, the application is installed along with the loadable policy module. Each time the application is run, the application is executed with the policy augmented by the application's policy module at the MAC level.
To identify what the permissions are for each application (e.g., Android™), each has a manifest file (e.g., AndroidManifest.xml) in its root directory. The manifest provides essential information about the application to the operating system platform. This information must be received by the operating system platform before the application can run any of the application's code. The manifest typically includes the following: (1) the manifest file names the Java package for the application where the package name serves as a unique identifier for the application; (2) the manifest file describes components of the application, for example, the activities, services, broadcast receivers, and content providers, that the application is composed of. The manifest file also names the classes that implement each of the components and publishes their capabilities (e.g., which internet messages they can handle). Such declarations allow the operating system platform to know what the components are and under what conditions they can be launched; (3) the manifest file determines which processes will host application components; (4) the manifest file declares which permissions the application must have to access protected parts of the API and interact with other applications; (5) the manifest file declares the permissions that other applications are required to have to interact with the application's components; (6) the manifest file lists instrumentation classes that provide profiling and other information as the application is running (such declarations may only be present in the manifest while the application is being developed and tested and are removed before the application is published); (7) the manifest file declares the minimum level of the Android API that the application requires; (8) the manifest file lists the libraries that the application must be linked against.
A permission is a restriction limiting access to a part of the code or to data on the device. This limitation is imposed to protect critical data and code that could be misused to distort or damage the user experience.
Each permission is identified by a unique label. The label often indicates the action that is restricted. The following are examples of permissions (e.g., permissions for Android):
Moreover,
A feature can be protected by at most one permission. If an application needs access to a feature protected by a permission, then the application must declare that it requires that permission with a <uses-permission> element in the manifest. Upon installation of the application on the mobile device, a user determines whether or not to grant the requested permission by checking the authorities that signed the application's certificates, and in some cases, asking the user. If the permission is granted by the user, then the application is able to use the protected features. If the permission is not granted, then an attempt to access those features will simply fail without any notification to the user.
An application can also protect its own components (activities, services, broadcast receivers, and content providers) with permissions. It can employ any of the permissions defined by the operating system platform listed in manifest permission file as declared by other applications or the application can define its own. A new permission is declared with the <permission> element. An example of an activity that can be protected is as follows:
In the above example, a DEBIT_ACCT permission is shown. The DEBIT_ACCT permission is not only declared with the <permission> element, its use is also requested with the <uses-permission> element. Its use must be requested for other components of the application to launch the protected activity, even though the protection is imposed by the application itself.
In the above example, if the permission attribute was set to a permission declared elsewhere (e.g., Android.permisssion.CALL.EMERGENCY_NUMBERS), it would not have been necessary to declare it again with a <permission> element. However, it would still have been necessary to request its use with <uses-permission>.
A <permission-tree> element declares a namespace for a group of permissions that will be defined in the code. A <permission-group> defines a label for a set of permissions, both those permissions 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 which permissions belong to the group; it just gives the group a name. A respective permission is placed in the group by assigning the group name to the <permission> element's “permissionGroup” attribute.
Once all high-level permissions are translated to low level MAC rules, they are all bundled into one loadable policy module and SELinux Policy module that can be enabled in the SELinux policy when application is executed.
The following is an example of how high level permissions can be mapped to corresponding low level MAC rules. The example involves an “internet” high-level permission in an application's manifest file and shows how it can be mapped to a set of SELinux MAC rules that allows the application to create a network socket, but restricts the application to only a specific type of socket and port.
The excerpt is an exemplary manifest file for the notional web-client application that requires the INTERNET permission is shown in
The SELinux MAC rules are mapped to the INTERNET permission for more fine-grained access control. This performed by showing how the application is defined within the SELinux policy language.
The first line defines a new type (domain) for the webclient, user_webclient_t, which is assigned the same access attributes as the more general class domain and the more general type application_domain_type. These are common attributes that are used on a wide variety of applications. The second line assigns a “role” to the application that is standard for most user-mode applications, user_r, and defines a further set of common restrictions.
Next, the application's use of the network is constrained as follows.
While the first line allows the application to create and manipulate a TCP network socket, the second line allows it to bind to, send, and receive packets on one of a designated HTTP ports. This is defined by http_port_t. The first line defines the HTTP port type http_port_t, which has the same attributes as the more general port_type and reserved_port_type. The tcp_socket class defines the operations allowed on a TCP socket.
The following are specific port numbers that are controlled by the http_port_t and are defined as follows:
Each line assigns a security context for the TCP protocol for one of the common port numbers associated with the HTTP protocol. The net result is that the webclient application is constrained to bind only to a TCP socket on a port associated with the HTTP protocol.
In addition, it can be illustrated how SELinux rules can be used to control the application's use of the network further, but constraining its ability to send and receive any packets other than those marked as HTTP packets.
As shown above, the HTTP packets are labeled in the SELinux policy as having the same attributes as the more general packet_type and client_packet_type. The rule constraining the application's use of such packets is as follows:
As shown in the rule, the application is constrained to only send and receive packets that have been marked as belonging to the identified HTTP protocol.
Finally, the rules are combined into a loadable policy module, which is shown in
The framework as described herein can also realize a sandboxing environment for various applications that are installed, but not trusted. In a sandboxing environment, the application will be installed and given the high-level permissions requests using the low-level MAC rules. The requested permissions will be highly restricted to make sure that they do not perform any malicious operations. For example, an application may request internet connectivity and access to private information stored on a phone, but the nature of the application does not justify transmission of private information off the phone and over a network. Therefore, a MAC rule can be added to the policy module to be installed on the operating system alongside the application, which prevents the application from reading any sensitive data (e.g., contacts stored on phone, location information) and initiating outbound network connections.
However, when imposing such constraints, there is the potential that the application may not function correctly even if it has legitimate reasons for executing both restricted activities. A further embodiment may be implemented, hereinafter referred to as a “sandbox agent” that interacts with the application and functions as a proxy between the application and its outside environment. MAC rules can then be implemented that will allow only outbound traffic from the suspicious application to the sandbox agent. The discretion resides with the sandbox agent to determine which outbound traffic to forward and which to block, thereby effectively sandboxing the suspicious application.
While certain embodiments of the present invention have been described in detail, those familiar with the art to which this invention relates will recognize various alternative designs and embodiments for practicing the invention as defined by the following claims.
This application claims priority of U.S. Provisional Application Ser. No. 61/909,451 filed Nov. 27, 2013, the disclosure of which is incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61909451 | Nov 2013 | US |
