GB2457305A

GB2457305A - Controlling access to system resources using script and application identifiers

Info

Publication number: GB2457305A
Application number: GB0802494A
Authority: GB
Inventors: Tim Gover; Steve Bannister
Original assignee: Nokia Oyj; Symbian Software Ltd
Current assignee: Nokia Oyj
Priority date: 2008-02-11
Filing date: 2008-02-11
Publication date: 2009-08-12
Also published as: GB0802494D0

Abstract

Access to a resource of a computing system by a client application executing a script is controlled. A request to access a system resource includes an identity pair comprising a client application identifier and a script identifier and access to the requested system resource is controlled in accordance with an access policy specified for the identity pair. In accordance with the access policy a user prompt may be generated and access to the resource controlled according to a response to the user prompt. A user prompt may be generated in the absence of an access policy for the specified identity pair. The response to the user prompt may be temporarily stored and subsequent access requests including the same identity pair actioned in the same way. The scripts may be arranged to be executed by one or more threads within the client application, each thread having an associated set of meta-data and wherein when a thread commences to thread a script the script's identifier is appended to the thread meta-data.

Description

Intellectual Property Office EDEC For Creativity anc on Application No GB0802494.5 RTM Date:22 May 2008 The following terms are registered trademarks and should be read as such wherever they occur in this document: Java UK lnteUectual Properly Office is an operating name of The Patent Office

METHOD AND SYSTEM FOR CONTROLLITG SYSTEM RESOURCE ACCESS

The general field of technology to which the current invention relates is that of controlling access to the resources of a computing device by a software application being executed on that computing device. It may be desirable to restrict access to the computing device's resources if such access could incur a financial cost, compromise privacy, cause damage to information or property or have a detrimental effect on the performance of the computing device itself For example, if the computing device in question is a mobile telecommunication device then it may be desirable to restrict access to the telecommunications network so as to avoid incurring unauthorised network usage charges.

Alternatively, where the computing device is a mobile computing device it is generally the case that battery power is considered a valuable device resource and access to certain hardware resources may be restricted so as to minimise power usage.

A common access control policy implemented on computing devices is to prompt the user whenever a software application attempts to access a restricted system resource and allow or deny access to that resource depending upon the response by the user to the prompt.

Generally, a database of access policies is maintained specifying whether or not particular applications are permitted access to certain system resources depending upon previously provided replies to user prompts.

The above mentioned user prompt methodology generally operates adequately when the software applications requesting access to the computing system resources are native applications, since the operating system of the computing device can easily intercept the access requests made by the native applications and apply the appropriate access control policy. In this context a native application is an application specifically arranged to be executed on a particular computing environment. For example, it may be originally written with a particular computing architecture and/or operating system in mind, or it may be compiled from source code for a particular architecture or operating system. It can thus execute directly on the environment without the need for emulation or interpretation. This is in contrast to a non-native application that is not native to a single platform or computing environment but is written with the intention of it being executed on a number of different computing environments. Typically this results in non-native applications being interpreted or emulated. An example of a common non-native application is a Java application. Another example of non-native applications are scripting languages. In this context a script can be considered as a sequence of instructions that is carried out by another program rather than directly implemented by the computer processor. As individual scripts when executed can make access requests to system resources it would be beneficial for any user prompt access control system to apply to such scripts. However, an individual script may be called and executed by one or more applications on the computing device and consequently to date user prompt access control systems can only apply access policies to individual applications, rather than individual scripts.

According to a first aspect of the present invention there is provided A method of controlling access to a system resource of a computing system by a client application executing a script, the method comprising generating an access request for the system resource, the access request inctuding an identity pair comprising a client application identifier and a script identifier and controlling access to the requested system resource in accordance with an access policy specified for the identity pair of the access request.

A user prompt may be generated in accordance with the access policy and access to the system resource controlled according to a response to the user prompt. Alternatively, in the absence of an access policy for the specified identity pair, a user prompt may be generated and access to the system resource controlled according to a response to the user prompt.

The response to the user prompt may be temporarily stored and subsequent access requests including the same identity pair are actioned in accordance with the temporarily stored user prompt response. The temporarily stored response is preferably deleted when the client application specified in the identity pair terminates.

The scripts may be arranged to be executed by one or more threads within the client application, each thread having an associated set of meta-data and wherein when a thread commences to execute a script, the script's identifier is appended to the thread meta-data.

The script identifier may comprise a script file-name or a value corresponding to an entry in a register of script names.

According to a second aspect of the present invention there is provided a system for controlling access to a system resource of a computing system by a client application executing a script, the system comprising a user prompt service including a data processing entity and an access policy database, the data processing entity being arranged to receive an access request for the system resource, the access request including an identity pair comprising a client application identifier and a script identifier, and control access to the system resource in accordance with an access policy stored in the access policy database specified for the identity pair.

The data processing entity is preferably arranged to generate a user prompt and control access to the system resource according to a response to the user prompt. Alternatively, in the absence of an access policy for the specified identity pair, the data processing entity may be arranged to generate a user prompt and control access to the system resource according to a response to the user prompt.

The user prompt service may be arranged to temporarily store the response to the user prompt and respond to subsequent access requests including the same identity pair in accordance with the temporarily stored user prompt response. Preferably, the user prompt service is arranged to delete the temporarily stored response when the client application specified in the identity pair terminates.

An embodiment of the present invention will now be described below, by way of non-limiting example only, with reference to the accompanying figures, of which: Figure 1 schematically illustrates a user prompt access control system according to an embodiment of the present invention; and Figure 2 schematically illustrates the basic process steps of an embodiment of the present invention.

A first embodiment of the present invention is schematically illustrated in Figure 1. The various elements illustrated in Figure 1 schematically represent different elements of a mobile computing device, such as a "smart" mobile telephone. Included within the system is at least one client application 2 comprising a first data processing entity. A characteristic of the client application is that it may request access to a service provided by the mobile computing device. For example, the client application may comprise an instant messenger or push-to-talk service that require a connection to a telecommunication network to which the mobile computing device is subscribed. Each client application 2 has an associated client ID, ID:C, that uniquely identifies different client applications provided on the same mobile computing device. Each client application data processing entity is capable of executing one or more processor threads 4, with each thread being capable of executing scripts. Each client application 2 is configured to communicate with one or more system servers 6, each system server comprising a further data processing entity that controls the operation of one or more system resources 8. Each system server 6 is capable of communication with a user prompt service 10, which provides the functionality for prompting the user of the mobile computing device to make a security decision as required.

The user prompt service includes a third data processing entity 12 in communication with an internal database 14 that contains one or more security policies for controlling access to certain system resources. The third data processing entity 12 of the user prompt service 10 is arranged to drive a user interface 16 as required that allows security prompts to be presented to the user of the mobile computing device. The user interface 16 may, for example, be a graphical user interface presented on a display screen but is not limited to any specific user interface or associated hardware. It will also be appreciated that the data processing entities associated with the client application, system server and user prompt service may either be implemented as individual, dedicated data processors or may be implemented as separate processes executed by a common data processor of the mobile computing device.

Figure 2 schematically illustrates the sequence of method steps involved in an embodiment of the present invention. The sequence is initiated at step 22 when a script being executed within a thread 4 of the client application 2 requests access to a particular system resource 8. The request is issued by the client application to the system server 6 handling the identified system resource. The request includes a paired identity including the client application ID (ID:C) and the thread ID (ID:T/D) of the thread executing the script requesting access to the particular system resource. The data processing entity of the system server 6 is arranged to determine whether or not access to the requesting system resource is restricted, indicated as step 24 in Figure 2. If access is not restricted then the system server 6 provides access to the requested resource without any further intervention -step 26. However, if the system server 6 determines that access to the identified system resource is restricted then the system server forwards the paired identity of the client ID and thread ID, together with details of the resource being requested, to the user prompt service 10. The user prompt service 10, and specifically the data processing entity 12 included within the user prompt service, is arranged to firstly search the internal database 14 to try to locate an existing access policy associated with the paired ID and system resource. This is indicated at step 28 in Figure 2. If an existing policy is located within the internal database 14 then the data processing entity 12 examines the policy to determine if a user prompt is required -step 30. An access policy may stipulate that a user prompt is always required regardless of previous user interventions, for example, or where the requested system resource permits access to personal user data it is therefore considered to require positive user permission each time the request is made for access to that system resource. Alternatively, an access policy may include provision to have a previous user intervention recorded, for example to store a previous user response indicating that all subsequent requests to that particular resource should be permitted. If the access policy dictates that a user prompt is required then the data processing entity 12 of the user prompt service 10 causes a suitable prompt to be given to the user of the computing device via the user interface 16 -step 32. Based on either the response provided by the user to the prompt or an existing decision of the relevant policy, the user prompt service 10 determines whether or not access to the requested service is to be permitted -step 34. If access is to be permitted then the system server 6 is notified accordingly and subsequently provides access to the requested system resource to the original requesting client application -step 26. If access is not permitted then a corresponding denial instruction is returned to the system server 6 -step 36 -and a corresponding error message subsequently returned to the client application from the system server 6 -step 38.

It is a characteristic of the present invention that the access requests by the identity pair contain both the client application ID 4 the script ID. However, for native client applications the script ID field may be null, since it is considered that for native applications it is sufficient to use only the application ID to define the access policy. For non-native applications the script ID may be any value that uniquely identifies the script, at least within the context of the client application. For example, it may be the file-name of the script or a key within a registry of scripts maintained by the client application. In embodiments of the present invention, when a thread within a client application starts executing a script the thread 4 tags its own meta-data with the script ID. Consequently, within the context of the present invention the script ID and thread ID can be considered interchangeable. The mechanism for assigning a script ID to the thread may, for example, include assigning an integer value that corresponds to the nth script belonging to a particular scripting host. Alternatively a helper process is provided that manages an in-memory register that maps thread IDs to integer values. In some implementations different scripting hosts may require different naming schemes for the client applications. In this case the user prompt service is arranged to delegate the task of resolving the script ID from the thread ID to a plug-in process specific to the scripting host.

For native applications, system servers may improve the performance of the access request process by caching the result of a user prompt if the user indicates that the identified client application is permitted access to the system resource either on a permanent basis or until the client application terminates. The system server and user prompt service subsequently use the cached result instead of repeatedly providing a user prompt each time the particular client application requests access to that resource. However, when a system resource is requested by a script this methodology is not appropriate because the scripting host (client application) may execute a number of individual scripts before itself terminating and it is not possible to determine when individual scripts have terminated. This problem is resolved by embodiments of the present invention by utilising the client application ID.

The internal policy database 14 of the user prompt service 10 is configured to allow known scripting hosts to be identified by their client application ID. Subsequently, when a system access request is received at the user prompt service it can be determined from the client application ID whether or not that client application is known to be a scripting host, If so, the user prompt service 10 is arranged to indicate to the system server 6 that the decision to permit or deny access to the system resource only applies to that single request and the result should not be cached.

However, it may be desirable to automatically allow the same script repeated access to a system resource on a temporary basis, so as to support an application "session". For example, it is undesirable that a user be prompted every time a share-price monitor requests access to a telecommunications network to update its data. This is achieved in embodiments of the present invention by maintaining a temporary database of resource access decisions for individual paired IDs of client application and script. This database is analogous to the permanent internal policy database 14 of the user prompt service except that entries are also tagged with the process ID of the client application, the process ID identifying the individual system process executing the particular client application. When an entry is added to the temporary database, the user prompt service requests that the system kernel of the computing device notifies the user prompt service when the client process exits. This allows redundant records to be removed from the temporary database whenever the client processes terminate. This temporary database is additionally accessed for any received access requests to determine if a decision has already been made by a user in respect of that particular current instance of client application and script. In preferred embodiments the temporary database is stored in the mobile device RAM for speed of access and to avoid fragmenting the main policy database 14. Additionally, there is no requirement for the temporary database to persist if the device is rebooted, since the client applications and scripts will have been terminated, hence the use of RAM is adequate.

It will be understood by the skilled person that alternative implementations are possible, and that various modifications of the methods and implementations described above may be made within the scope of the invention, as defined by the appended claims.

Claims

CLAIMS1. A method of controlling access to a system resource of a computing system by a client application executing a script, the method comprising: generating an access request for the system resource, the access request including an identity pair comprising a client application identifier and a script identifier; and controlling access to the requested system resource in accordance with an access policy specified for the identity pair of the access request.
2. The method of claim 1, wherein in accordance with the access policy a user prompt is generated and access to the system resource is controlling according to a response to the user prompt.
3. The method of claim 1, wherein in the absence of an access policy for the specified identity pair, a user prompt is generated and access to the system resource is controlled according to a response to the user prompt.
4. The method of claim 2 or 3, wherein the response to the user prompt is temporarily stored and subsequent access requests including the same identity pair are actioned in accordance with the temporarily stored user prompt response.
5. The method of claim 4, wherein the temporarily stored response is deleted when the client application specified in the identity pair terminates.
6. The method of any preceding claim, wherein the scripts are arranged to be executed by one or more threads within the client application, each thread having an associated set of meta-data and wherein when a thread commences to thread a script the script's identifier is appended to the thread meta-data.
7. The method according to any preceding claim, wherein the script identifier comprises a script file-name. c
8. The method according to any one of claims 1 to 6, wherein the script identifier comprises a value corresponding to an entry in a register of script names.
9. A system for controlling access to a system resource of a computing system by a client application executing a script, the system comprising a user prompt service including a data processing entity and an access policy database, the data processing entity being arranged to receive an access request for the system resource, the access request including an identity pair comprising a client application identifier and a script identifier, and control access to the system resource in accordance with an access policy stored in the access policy database specified for the identity pair.
10. The system of claim 9, wherein the data processing entity is arranged to generate a user prompt and control access to the system resource according to a response to the user prompt.
11. The system of claim 9, wherein in the absence of an access policy for the specified identity pair, the data processing entity is arranged to generate a user prompt and control access to the system resource according to a response to the user prompt.
12. The system of claim 10 or 11, wherein the user prompt service is arranged to temporarily store the response to the user prompt and respond to subsequent access requests including the same identity pair in accordance with the temporarily stored user prompt response.
13. The system of claim 12, wherein the user prompt service is arranged to delete the temporarily stored response when the client application specified in the identity pair terminates.
14. The system of any one of claims 9 to 13, wherein the script identifier comprises a script file-name.
15. The system of any one of claims 9 to 13, wherein the script identifier comprises a value corresponding to an entry in a register of script names.