HK1119321B - Running internet applications with low rights - Google Patents

Description

Running internet applications with low permissions

Technical Field

The invention relates to running internet applications with low permissions.

Background

Many different types of applications are capable of interacting with and obtaining data or other information from the internet. For example, some applications can allow a user to download specific content, such as web pages, files, and the like. The various hazards associated with such interaction also arise with the ability to interact with the internet.

For example, through the various interactions that occur between applications and the internet, so-called malware (malware) or spyware (spyware) can be downloaded to user systems and can deleteriously affect system performance, and perhaps more importantly, can unauthorized installation of malware. For example, buffer overflow (buffer overflow) and other security holes can allow malicious software to maliciously enter the user's system.

Regarding influencing the system performance, consider the following. In some instances, malware may attempt to, or may actually change, security settings associated with a particular application or with the user's system as a whole, thereby making malicious tampering more likely to occur.

Against this and other background of security concerns, software developers still often desire to provide users with a secure, rich experience.

SUMMARY

In various embodiments, an application configured to interact with the Internet in some manner is executed in a restricted process having a reduced privilege level that may prohibit the application from accessing portions of the computing device. For example, in some embodiments, a restricted process can prohibit read and write access by applications to portions of a system's computer-readable medium, such as a hard disk, that contain management data and settings information as well as user data and settings. In these embodiments, a particular portion of disk, referred to as a "containment zone," is specified and used by applications in this restricted process.

In other embodiments, a broker mechanism (broker mechanism) is utilized and logically inserted between the application and the restricted portion or containment zone of the computing system. The broker mechanism brokers access to the restricted portions and ensures that the user is aware of and able to approve access of the application to the restricted portions of the computing system.

In other embodiments, a shim mechanism (shim mechanism) is used to redirect access to containment zones, typically for third party extensions.

In other embodiments, application execution in a restricted process may result in another application being launched that is functionally similar to the restricted application, yet less restricted to facilitate the user experience in a particular context that has been deemed trustworthy or at least as secure as desired.

Brief Description of Drawings

FIG. 1 is a block diagram of a system according to one embodiment. FIG. 2 is a block diagram of a system according to one embodiment.

FIG. 3 is a flow diagram that describes steps in a method in accordance with one embodiment.

FIG. 4 is a block diagram of a system according to one embodiment.

FIG. 5 is a block diagram of a system according to one embodiment.

FIG. 6 is a block diagram of a client computing device, in accordance with one embodiment.

Detailed Description

Overview

In the embodiments described below, an application configured to interact with the Internet in some manner is executed in a restricted process having a reduced privilege level that may prohibit the application from accessing portions of the computing device. For example, in some embodiments, a restricted process can prohibit read and write access by applications to portions of a system's computer-readable medium, such as a hard disk, that contain management data and settings information as well as user data and settings. In these embodiments, a particular portion of the disk, called the "containment zone," is specified and used by applications in this restricted process.

In other embodiments, an agent mechanism is utilized and logically interposed between the application and the restricted portion or containment zone of the computing system. The broker mechanism brokers access to these restricted portions and ensures that the user is aware of and able to approve access by the application to these restricted portions of the computing system.

In other embodiments, a shim mechanism is used to redirect access to containment zones, typically for third party extensions.

In other embodiments, application execution of a restricted process may result in another application being launched that is functionally similar to the restricted application, yet less restricted to facilitate a user experience in a particular context that has been deemed trustworthy or at least as secure as desired.

The techniques described in this document may be used in connection with any type of application that interacts with the internet. The skilled artisan will appreciate that there are many variations of these types of applications. However, to provide a practical context for understanding embodiments of the invention, an application in the form of a web browser application is utilized. It is to be appreciated, however, that the techniques can be utilized with other types of applications without departing from the spirit and scope of the claimed subject matter. By way of example and not limitation, these other types of applications include instant messaging clients, peer-to-peer clients, RSS readers, email clients, word processing clients, and the like.

Restricting internet applications and using agents

FIG. 1 illustrates a high-level view of a system 100 in accordance with one embodiment. In this example, system 100 includes an Internet application in the form of a web browser 102 that can interact with the Internet. The system 100 also includes a computer-readable medium 104, such as hard disk instructions, that contains different portions or "spaces" that contain different types of information, setup data, and the like.

In this example, one portion or space is a management space 106 that includes information and data that is typically accessible and operable by a system administrator. This type of information and data may include information and data that is typically contained in operating system folders, computer system folders, persistent file folders, and the like. This space typically requires administrators to have the proper credentials and privileges to have their content accessible and manipulated.

The other portion or space is a user space 108 that includes user information and data. This type of information and data may include information and data that is typically contained in user accessible folders such as "my documents," "my music," "desktop," and the like. This space is typically associated with fewer privileges so that access may be granted.

According to one embodiment, the computer-readable medium 104 includes one or more containment zones 110. The containment zone is the only zone that can be written directly by browser 102, at least in some embodiments. To facilitate this functionality, a wall or blocking mechanism 112 is provided that prevents the browser 102 from writing directly to the administrative space 106 or the user space. In at least some embodiments, the containment zone allows for the setting of restricted applications between sessions to be saved to a location where they cannot contaminate any other applications on the machine. The containment zone may include a number of registry locations and file folders. In the context of a web browser application, containment zone 110 may include temporary internet folders that are used to improve web page load time and cache other types of data.

Thus, in this embodiment, one or more containment zones are specifically defined and designated as part of those computing devices that are accessible to an internet application, such as a web browser application. This is different from simply denying access to portions of the disk and allowing access to other portions based on the particular user that may attempt such access. In contrast, in the present type of approach, the restrictions are application-centric, not necessarily user-centric. That is, the inventive approach may be considered user independent. This approach helps ensure that only a few (e.g., a minimum) of the required locations are exposed in the lockdown area, and it also helps ensure that other applications do not store settings in the lockdown area. In addition, this application-centric approach can make both administrative and user space inaccessible to the application.

Thus, in this regard, a wall or blocking mechanism 112 is logically interposed between browser 102 and certain predefined spaces, such as administrative and user spaces, to prevent the browser from directly accessing such spaces. However, in some instances, it may be desirable to allow an application to access administrative or user space. For example, a user who is a system administrator may wish to legally operate some system settings. In addition, a conventional user may wish to save a photograph to the My documents folder.

In this embodiment, an agent mechanism is utilized and logically inserted between the application (in this case browser 102) and the restricted portion or containment zone of the computing system. The broker mechanism brokers access to these restricted portions and ensures that the user is aware of and able to approve access by the application to these restricted portions of the computing system.

By way of example, consider fig. 2, where like numerals from the fig. 1 embodiment are used. Wherein an agent mechanism is provided in the form of agent objects 200, 202. In this example, proxy object 200 is a management space proxy object that proxies access to management space 106. Proxy object 202, on the other hand, is a user space proxy object that proxies access to user space. The broker mechanism can be implemented in any suitable manner using any suitable type of object. In one implementation, each broker object is implemented as a DCOM local server object. In addition, the broker object runs in a process separate from browser 102, thereby providing some degree of protection against attacks by malicious code targeted at browser 102. Additionally, in at least one implementation, the broker objects are task-based and their lifetimes are defined by the tasks that they are to accomplish.

In this instance, when an application, such as browser 102, wishes to access a particular restricted space, such as an administrative or user space, the application invokes the associated broker object, which then examines the application's request. The broker object may check the request for a number of reasons, including ensuring that it is a well-formed request, or checking an electronic signature on a file that the application is downloading. Once the request has been examined, the broker object takes action to broker access to the restricted space.

In some embodiments, this may include prompting the user to determine whether the user wishes to access the space in the manner represented in the requirement. For example, if the user is attempting to save a photo to their "my documents" folder, the broker object may simply ask the user through an appropriate dialog box whether this is the user's intent. If validated, the broker object may allow and facilitate the access. Alternatively or additionally, if the user is an administrator and is attempting to write to the administrative space, the broker object may request that the administrator enter their credentials. In this manner, access to the restricted space can be maintained. In these examples, the broker object performs a write or modify to the restricted space to extract the process from the application that is initiating the call.

Thus, the wall or blocking mechanism 112 and agent mechanisms 200, 202 work together to block access to restricted portions of the disk, but not to those portions where appropriate.

Having explored the concept of a wall or blocking mechanism and a broker mechanism, the following discussion provides only one example (along with an alternative example) of how the blocking mechanism may be implemented. It is to be recognized and understood that the blocking mechanism and the agent mechanism can be implemented in other ways without departing from the spirit and scope of the claimed subject matter.

Blocking mechanism-implementation example

In the following discussion, a blocking mechanism is described in the context of a tokenization system that imposes low rights on internet applications. The imposition of low rights in turn causes restrictions on the application's access to specific parts of the client system, such as administrative and user space. In a first embodiment, tokens that are not necessarily built to inherently allow this type of application-centric functionality are processed and reconfigured to implement this functionality. In a second embodiment, the token is built with a so-called "integrity level" to allow the above-described application-centric functionality.

First embodiment-reconfiguration token

In many systems, when a user runs or executes an application, the application executes in the context of the user. This means that the user typically has user data such as a user name and user privileges that restrict the execution of the application. More specifically, the username and privileges can be represented by and in the context of a token. Thus, when a user executes an application, the application, via the token, can know and inherit aspects of the user context, such as user privileges. Thus, if the user is a system administrator, the association token identifies the user as a system administrator, and the application inherits the system administrator privileges, which in turn allows the application to write to the administrative space.

FIG. 3 is a flow diagram that describes steps of a token processing method in accordance with one embodiment. The method can be implemented in any suitable hardware, software, firmware, or combination thereof. In one embodiment, aspects of the method are implemented by a suitably configured application, such as browser application 102 in FIGS. 1 and 2.

Step 300 launches an application, which in this example is a web browser such as the browser shown and described above. When a user launches the application, the token associated with the user becomes available for use by the application from which the user privileges can be inherited as described above.

Step 302 determines the user type. There may be different types of users, such as administrative users, advanced users (power users), backup operators, and so on. Step 304 removes privileges associated with the user type. In the illustrated embodiment, this step is accomplished by effectively manipulating the data of the token to remove a flag indicating any privileges associated with the token and thus with the user type. This step essentially creates a block to a management space of the computing device, such as management space 106 in fig. 1 and 2.

Step 306 adds a restriction on user space. In the illustrated and described embodiment, this is accomplished by effectively manipulating the data of the token to remove the username from the token. By removing the username from the token, the privileges associated with a particular user are also removed.

Step 308 then defines one or more containment zones for the read/write access. In this particular example, this step is implemented by replacing the removed username with a specifically defined user group name (e.g., "IEUsersGroup"). Now, for one or more of the containment zones, these are the only zones designated for read/write access by members of the specifically defined group name.

Thus, at this point, any administrative privileges have been removed, effectively blocking administrative space. Likewise, user privileges have been removed, blocking access to user space. However, by changing the username to a special group name and associating the special group name with one or more containment zones, the application's read/write access is now limited to only the one or more containment zones described above.

More specifically, proceeding as described above, step 310 terminates the old process associated with the launched application, and step 312 creates a new process for the application with the reconfigured token.

With this reconfigured token, the application will not have direct access to the administrative space or user space. Instead, the application will only be able to write directly to the containment zone, and will not be able to have data written to the user or administrative space without further intervention (e.g., by a human agent mechanism).

Second embodiment-Using integrity level

In another embodiment, the token is utilized and built by a so-called "integrity level" allowing the above-described application-centric functionality. That is, tokens associated with a user have different Integrity levels, such as may be set to "high", "medium", and "low", by a process called a Mandatory Integrity Control (regulatory Integrity Control). Likewise, a computing resource on a client device has an associated integrity level, and in order to access the resource, the resource must have the same or a lower integrity level as the user integrity level.

Thus, for example, by establishing the integrity levels of the administrative and user spaces as "high" and "medium", respectively, and the integrity of the user as "low", access to the administrative and user spaces can be effectively blocked. However, designating the containment zone as having a "low" level of integrity allows the user to access the containment zone through whatever application the user is using.

Using a backing layer

In at least some embodiments, a shim mechanism such as shim 400 in FIG. 4 is used to redirect access to containment zones, typically for third party extensions. More specifically, in the context of a browser application, many different third party extensions may be provided and run in conjunction with or within the browser. For example, the Google toolbar is an example of an extension designed to run within a browser.

Certain extensions typically require write access to portions of the file system or registry in order to function properly. For example, the Google toolbar may wish to keep a list of favorite searches for a particular user. However, this type of writing is blocked by the wall or blocking mechanism 112 if the user space is not accessed.

According to one embodiment, when application 102 or an associated third party component attempts to write to a restricted space, shim 400 is configured to trap and redirect the call and write data to the containment zone. Subsequent calls by the application to the data redirected to the containment zone are handled by the shim and the appropriate data is retrieved from the containment zone. Thus, data that a particular extension or application wants to write to administrative or user space is redirected to the appropriate containment zone.

This allows third party extensions to continue working without requiring any third party code to be rewritten. In operation, the third party extension believes that it is writing data to a user or administrative space. However, through the shim mechanism, such data is written to and read from the containment zone.

Launching unrestricted application

As described above, in other embodiments, execution of an application in a restricted process may result in another application being launched that is functionally similar to the restricted application, yet less restricted to facilitate the user experience in a particular context that has been deemed trustworthy or at least as secure as desired.

As a more practical example, consider the following in the context of a browser. Assume that a corporate user may access the internet and corporate intranet through their client computing device. It is also assumed that corporate intranets are secure and trusted entities. Assume further that the user's computing device is executing several different business applications that require a high degree of compatibility to remain properly functioning. In such and other contexts, when executed in the context of a corporate intranet, it is desirable to be able to allow applications to operate in an unrestricted manner-i.e., in a manner that is unrestricted by blocking mechanism 112.

By way of example, consider fig. 5 in conjunction with the following. There are specific contexts in which an application may attempt to run, and these contexts belong to specific regions that have been defined as trustworthy or otherwise with a level of security that has been defined as "secure". In the browser example, the user may attempt to navigate to a corporate intranet or other secure area. In this case, restricted browser 102 invokes a broker mechanism that, based on the call being made by the application, can instantiate an unrestricted browser 500 with which the user can operate in the particular area to which they have navigated. In this example, a token is created and configured to include privileges associated with the user (e.g., administrative privileges, high-level user privileges, etc.) and a username associated with the user, thereby providing the user access to the appropriate portion of the user space.

Additionally, in this embodiment, containment zones are defined in a manner that maintains isolation between restricted and unrestricted browsers 102 and 500, respectively. More particularly, recall that a containment zone in the form of a temporary internet folder is provided to which restricted browser 102 and other components can read and write. However, in this embodiment, if the unrestricted browser 500 uses this containment zone to write temporary internet files, there is an opportunity for the restricted browser to access this data or use this containment zone overlap to attempt to maliciously gain access to the portion of the computing device that it should not be able to access.

Thus, to address this and other situations, different containment zones are defined, one of which is associated with restricted browser 102 and the other containment zones are associated with unrestricted browser 500 and isolated from the restricted browser. In the illustrated example, the containment zone 110a is associated with the browser 102 and is only usable by the browser 102. Moreover, the containment zone 110b is associated with the unrestricted browser 500 and is only usable by the browser 500. Neither browser can read from or write to the other associated containment zone. It is thus observed that wall 112 expands downward and blocks access to containment zone 110b from restricted browser 102.

In the above implementation where the token is processed and reconfigured, the containment zone 110a is designated as being readable from and writable to only by the group identified in the token. Thus, applications executing in the context of this token cannot access the containment zone 110 b.

Exemplary usage scenarios

The following usage scenario provides some additional examples of how the above-described embodiments of the invention may be utilized in the context of a web browser.

Consider first an example in which embodiments of the invention may be used to protect a user. Suppose user Abby visits a web site that installs a control using buffer overflow in the browser. Here Abby navigates to a page that uses a buffer overflow vulnerability in the browser to inject native code into the process space. The native code downloads a Dynamic Link Library (DLL) into a folder on her machine and attempts to register as an ActiveX control loaded by the browser by creating an entry in the registry. However, here the operation fails because the browser is not allowed to write to the registry. Abby then receives a notification to continue browsing securely.

As another example, assume that user Abby accesses a website that attempts to overwrite the system using the controls she has installed. Here Abby navigates to a page containing an already installed ActiveX control. The control attempts to overwrite a DLL in her system folder. Here, however, the operation is denied and Abby receives a notification informing her that the page is attempting to perform a privileged operation. She then continues to browse securely.

Consider now an example in which embodiments of the invention can be used to maintain the compatibility of Abby's system. Here, assume Abby upgrades her video driver from a website. Abby navigates to the website and clicks on a link to the driver. The file is downloaded and the executable installation agent (i.e., agent mechanism) prompts Abby to confirm that she trusts the executable and wishes to install it. If the installation is successfully completed as approved by Abby, Abby continues to browse securely.

Now assume that Abby visits her favorite web site. A new menu control has been added and the browser needs to install the control. Abby is prompted to ask if she trusts the control and authorizes the installation. If approved, the control is installed and Abby continues to navigate to the website and browse securely.

Exemplary computing System

FIG. 6 illustrates an exemplary computer system having components that can be used to implement one or more of the embodiments described above.

Computer system 630 includes one or more processors or processing units 632, a system memory 634, and a bus 636 that couples various system components including the system memory 634 to processors 632. Bus 636 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory 634 includes Read Only Memory (ROM)638 and Random Access Memory (RAM) 640. A basic input/output system (BIOS)642, containing the basic routines that help to transfer information between elements within computer 630, such as during start-up, is stored in ROM 638.

The computer 630 further includes a hard disk drive 644 for reading from and writing to a hard disk (not shown), a magnetic disk drive 646 for reading from or writing to a removable magnetic disk 648, and an optical disk drive 650 for reading from or writing to a removable optical disk 652 such as a CD ROM or other optical media. The hard disk drive 644, magnetic disk drive 646, and optical disk drive 650 are connected to the bus 636 by a SCSI interface 654 or other suitable interface. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computer 630. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 648 and a removable optical disk 652, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Random Access Memories (RAMs), Read Only Memories (ROMs) and the like may also be used in the exemplary operating environment.

Some program modules may be stored on the hard disk 644, magnetic disk 648, optical disk 652, ROM 638, or RAM 640, including an operating system 658, one or more application programs 660, other program modules 662, and program data 664. A user may enter commands and information into the computer 630 through input devices such as a keyboard 666 and pointing device 668. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to processing unit 632 through an interface 670 that is coupled to bus 636. A monitor 672 or other type of display device is also connected to the bus 636 via an interface, such as a video adapter 674. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computer 630 typically operates in a networked environment using logical connections to one or more remote computers, such as a remote computing device 676. The remote computer 676 can be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 630, although only a memory storage device 678 has been illustrated in fig. 6. The logical connections depicted in FIG. 6 include a Local Area Network (LAN)680 and a Wide Area Network (WAN) 682. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 630 is connected to the local network 680 through a network interface or adapter 684. When used in a WAN networking environment, the computer 630 typically includes a modem 686 or other means for establishing communications over the wide area network 682, such as the Internet. The modem 686, which may be internal or external, is connected to the bus 636 via the serial port interface 656. In a networked environment, program modules depicted relative to the personal computer 630, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Generally, the data processors of computer 630 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of the computer. When executed, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described below.

For purposes of illustration, application programs and other executable program components, such as the operating system, are illustrated as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.

Conclusion

The embodiments described above can reduce the security risks associated with applications that may access the internet while still providing a secure, rich experience to the user.

Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.

Claims (14)

1. A computer-implemented method, comprising:

launching an internet application that inherits the privileges of a token associated with a user;

providing a blocking mechanism configured to block access by an internet application to a defined space of a client computing device on which the internet application is executed, wherein the defined space includes a management space and a user space of the client computing device, and providing the blocking mechanism includes reconfiguring the token associated with the user by:

removing privileges from the token associated with the user to block access to the administrative space by the internet application;

removing the user's username from the token to block access to the user space by the internet application;

defining a containment zone in which at least one of said internet applications will write and read data;

replacing the removed user name on the token with a group name of a group permitted to access the at least one containment zone to allow access by the internet application to the at least one containment zone; and

the old process associated with the internet application is terminated and a new process is created for the internet application with the reconfigured token.

2. The method of claim 1, wherein the blocking mechanism is configured to block access in a user-independent manner.

3. The method of claim 1, further comprising logically inserting a broker mechanism between the internet application and the defined space to broker access to the defined space.

4. The method of claim 3, wherein the agent mechanism comprises separate agent objects, each of the separate agent objects being associated with a different defined space.

5. The method of claim 3, wherein the broker is configured to enable a user to grant access to an associated defined space.

6. The method of claim 1, wherein providing a blocking mechanism is performed by setting an integrity level on a token associated with a user of the internet application.

7. The method of claim 1, wherein the internet application comprises a web browser application.

8. The method of claim 1 further comprising, as a result of user interaction with the internet application, launching a different internet application that is not blocked by a blocking mechanism and that uses a containment zone that is isolated from the at least one containment zone.

9. A computer-implemented method, comprising:

launching an internet application that inherits the privileges of a token associated with a user;

providing a token-based blocking mechanism configured to block access by an internet application to at least an administrative and user space of a client computing device on which the internet application is executed, wherein providing the token-based blocking mechanism comprises reconfiguring the token associated with the user by:

removing privileges from the token associated with the user to block access to the administrative space by the internet application;

removing the user's username from the token to block access to the user space by the internet application;

defining a containment zone in which at least one of said internet applications will write and read data;

replacing the removed user name on the token with a group name of a group permitted to access the at least one containment zone to allow access by the internet application to the at least one containment zone;

logically inserting a management agent object between the internet application and the management space to agent access to the management space;

logically inserting a user space broker object between the internet application and the user space to broker access to the user space; and

the old process associated with the internet application is terminated and a new process is created for the internet application with the reconfigured token.

10. The method of claim 9, wherein the broker object is configured to enable a user to grant access to an associated defined space.

11. The method of claim 10, wherein the management agent object is configured to prompt a management user to enter association credentials to access the management space.

12. The method of claim 9, wherein providing a token-based blocking mechanism comprises setting an integrity level on an associated token.

13. The method of claim 9, wherein the internet application comprises a web browser application.

14. The method of claim 9, further comprising, as a result of user interaction with the internet application, launching a different internet application that is not blocked by a blocking mechanism and that uses one of the containment zones that is isolated from the at least one containment zone.