This disclosure relates generally to the field of computer security. More particularly, but not by way of limitation, it relates to a technique for controlling the installation of applications on a programmable device.
Smartphones and other personal programmable devices often allow users to install applications on the personal programmable device to add additional functionality to the device beyond that provided by the manufacturer. While such applications can be useful and valuable to users, malware that presents a risk to the user or the programmable device is preferably not installed. Current systems for controlling installation of applications requires too much knowledge on the part of the user, and users have developed a response of accepting application installation without understanding the risks involved in installing the application, thus malware is often installed that could have been blocked if the user had understood the information about the application.
A programmable device for which an application is to be installed analyzes permissions requested by the application and other application information to assist the user in deciding whether to allow installation of the application. The analysis may either block or allow the installation, or may provide a calculated risk level to the user and request a decision. Application information, such as a category of application, typical permissions requested by similar applications, and trustworthiness of the application source, in addition to whitelists and blacklists may be employed as part of the analysis and evaluation of the permissions. As a result, the user need not be burdened with overly technical information and may make a better informed decision on installation.
A method is disclosed, wherein the method comprises receiving a request to install an application on a programmable device; and deciding whether to install the application, wherein deciding whether to install the application comprises determining a risk level of the application responsive to a set of permissions requested by the application; and blocking installation of the application if the risk level exceeds a predetermined risk threshold.
A system is disclosed, wherein the system comprises a processor; a storage subsystem, coupled to the processor; an application database stored on the storage subsystem comprising: information associated with applications configured for installation on a programmable client device; and software stored on the storage subsystem comprising instructions to cause the processor to perform actions, wherein the actions comprise receiving a request from the programmable client device to install an application on the programmable device; evaluating a set of permissions requested by the application; and transmitting a risk determination to the programmable client device responsive to evaluating the set of permissions.
A programmable device is disclosed, wherein the programmable device comprises a programmable control device; an operating system configured to control the programmable control device; a storage subsystem, coupled to the programmable control device; and software that when executed by the programmable control device, causes the programmable control device to perform actions comprising evaluating a set of permissions requested by an application to be installed on the programmable device to determine a risk level of the application; and blocking installation of the application if risk level exceeds a predetermined risk threshold.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.
Although the description below is written in terms of permissions requested by an application, any other collection of attributes requested or required by an application may be used instead of permissions.
Smart phones and other mobile programmable devices, including tablets, allow the installation of applications to extend the functionality provided by the hardware and the operating system and native applications. Where the hardware manufacturer is different from the manufacturer of the operating system that controls the programmable device, such as is commonly the case in systems using the Android operating system, the manufacturer of the hardware may modify the operating system provided by the operating system manufacturer, providing additional applications or operating system functionality, or restricting functionality as desired.
In devices using the Android operating system, for example, users may download applications from one of multiple application marketplaces for installation on their device. As part of the installation package, each application provides a manifest file that identifies what operating system capabilities (typically referred to as “permissions”), are required by the application. An application not granted a permission is prohibited by the operating system from accessing or using the associated capability. While some applications might be able to function without any permissions, most applications require one or more permissions.
Some permissions are essentially innocuous and safe. Other permissions may involve risk to the user, the user's personal data, etc. These permissions may be categorized based on the risks involved. For example, the Android operating system provides a standard set of permission groups as set forth in Table 1 below:
Application developers may also specify non-standard permission groups as desired.
Example permissions that may create a risk that the application using that permission may cost the user money include:
CALL_PHONE—the ability to initiate phone calls without notifying the user of the phone.
SEND_SMS—the ability to send Short Message System (SMS) messages without notifying the user of the phone.
INTERNET—the ability to open network sockets, potentially incurring data usage charges.
Example permissions that can access personal data include:
GET_ACCOUNTS—Allows access to the list of accounts in the Accounts Service.
GET_TASKS—Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
READ_CONTACTS—Allows an application to read the user's contacts data.
Example permissions that can modify personal data include:
CLEAR_APP_USER_DATA—Allows an application to clear user data.
WRITE_CONTACTS—Allows an application to write (but not read) the user's contacts data.
WRITE_SMS—Allows an application to write SMS messages.
Examples of permissions can be used for tracking the user's location include:
ACCESS_COARSE_LOCATION—Allows an application to access coarse (e.g., Cell-ID, WiFi) location/
ACCESS_FINE_LOCATION—Allows an application to access fine (e.g., GPS) location.
CAMERA—Required to be able to access the camera device.
Other permissions that can be used by malicious software to do other actions that might not be desired include:
FACTORY_TEST—allows root access to the phone and could be used maliciously.
AUTHENTICATE_ACCOUNTS—Allows an application to act as an AccountAuthenticator for the AccountManager.
BRICK—Required to be able to disable the device (very dangerous!).
These categories are illustrative and by way of example only, and other categories of permissions and specific permissions defined by the operating system may be considered risky when requested by an application.
Although in the case of Android operating systems, application installation warning screens are provided specifying the requested permissions, these warning screens are often ignored, because they are often too technical for end users to determine if the permissions requested are appropriate. A better approach described herein removes the need for the end user to understand the permissions that are requested by the application at the time of installation. This simplifies application installation and gives the user additional peace of mind that an application was not malicious.
By providing the capability for a security service (which may be integrated into the operating system, installed as an application, etc.) to evaluate the permissions requested by the application and make decisions on the level of risk created by the installation of the application, the application installation procedure may provide the user with control over the installation process, without requiring knowledge of the permissions requested or their individual or collective risks. The default behavior of the security service may be configured to provide control over the action of the security service. For example, the security service may block a risky application from installing without requesting a decision by the user. Alternately, the security service may allow the user to choose to install the risky application, but give the user an indication the level of risk before making the decision to install. Although numerous techniques may be provided for such an indication, one technique may present a warning dialog that indicates a low, medium, or high risk by color coded messages, using colors such as green, yellow, and red to accentuate the risk level information. The security service may further be configurable to allow a user to specify a level of risk that would be allowed to install without user approval, for example allowing applications deemed to be at a low risk to install without requiring approval, but requiring approval for applications deemed to be at a high risk. Any number of risk levels may be defined as desired.
In block 120, the requested permissions are obtained by the security service. In the case of an Android operating system, the permissions are provided by the application in a manifest file, generally formatted as an eXtended Markup Language (XML) file that is stored in the root directory of the application. Other operating systems may provide the permissions to the security service in any desired way.
In block 130, the security service evaluates the requested permissions, as described in more detail below. As a result of this evaluation, the security service determines a risk level of the application. In block 140, if the permissions create a risk level that is unacceptable, the security service may take actions to block the installation.
If the risk level is acceptable, the security service may take actions to allow the installation. Although as illustrated in
As illustrated in
In block 210, the requested permissions are evaluated to determine whether any of the requested permissions are deemed risky. If no permissions are requested, or install.
If block 220, the security service may check to see if the application is listed in a whitelist. The whitelist may be maintained locally, on the programmable device, remotely on a security server, or both, as described in more detail below. If a local whitelist is maintained, then the security server may provide periodic updates to the local whitelist, either replacing the local whitelist with a new version or making changes to the local whitelist as instructed by the security server. If only a remote whitelist is maintained, then block 220 may be implemented by sending a request to the security server, receiving a response indicating whether the application is listed on the remote whitelist. If both remote and local white lists are maintained, then the local whitelist is typically checked first, then the remote whitelist, although that order may be reversed if desired. If the application is on the whitelist, then the application may be considered not risky.
In block 230, a blacklist may be checked, similar to the check of the whitelist, using either local, remote, or a mixture of local and remote blacklists. Although as illustrated in
In block 240, if the application is on neither the whitelist nor the blacklist, the security service may use various criteria to determine the risk level of the application. As illustrated in
Although as illustrated in
In block 270, the permissions themselves are evaluated in light of the other information obtained in blocks 240, 250, and 260. If the permissions are deemed excessive, such as when an application similar to the current application usually only needs a subset of the permissions requested by the current application, then the application may be considered risky and a risk level assigned in block 280. Otherwise, the application may be considered not risky or having a low risk.
All or some of the actions of
The security service performing the techniques described above may be implemented as a standalone application or operating system service, or may be bundled as part of a broader security and anti-malware software as desired.
Implementation in an Electronic Device
Storage subsystem 314 may store media (e.g., image and video files), software (e.g., for implementing various functions on device 300), preference information, device profile information, and any other suitable data. Storage subsystem 314 may include one more storage mediums for tangibly recording image data and program instructions, including for example, a hard-drive, permanent memory such as ROM, semi-permanent memory such as RAM or flash memory, or cache. Program instructions may comprise a software implementation encoded in any desired language (e.g., C or C++).
Memory 312 may include one or more different types of memory which may be used for performing device functions. For example, memory 312 may include cache, ROM, and/or RAM. Communications bus 322 may provide a data transfer path for transferring data to, from, or between at least storage subsystem 314, memory 312, and processor 316. Although referred to as a bus, communications bus 322 is not limited to any specific data transfer technology. User interface 318 may allow a user to interact with the programmable device 300. For example, the user interface 318 can take a variety of forms, such as a button, keypad, dial, a click wheel, or a touch screen.
In one embodiment, the programmable device 300 may be an electronic device capable of providing personal communications. For example, the programmable device 300 may be a device such as such a mobile phone, personal data assistant (PDA), portable music player, monitor, television, laptop, desktop, and tablet computer, or other suitable personal device.
Networked Implementations
The network 420 may be a wireless network, such as a mobile phone wireless network, a wireless (WiFi) local area network, which may be connected to a wide area network such as the Internet. As described above, the phone 410 may communicate information about an application that is to be installed to the server 430. The server 430 may respond with a risk determination with information about the risk level of the application, or other information that may be used by the phone 410 to determine the risk level. Whitelist or blacklist information may be provided from time to time by the server 430 to the phone 410. In some variants, the phone 410 may perform the analysis and evaluation of the application, but provide the analysis or evaluation results to the server 430 for further analysis or for building a reputation database by the security service vendor.
The server 430 may update the whitelist by sending a revocation notice to cause the client to remove the application from its local whitelist or by sending a revocation notice to remove the application from its local blacklist, as additional information is learned by the server 430.
Similarly, the client 410 may provide updates to a remote whitelist or blacklist, based on analysis of an application by the client 410. Encryption may be used on the communications between the client 410 and server 430, and the whitelists and blacklists may be encrypted on either or both the client 410 and server 430 as desired. Any portion of the techniques described above may be performed on either the phone 410 or the server 430 as desired.
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.