Patent Application
20090007256
Companies and individuals currently face the challenge of maintaining control over their computers in response to constantly evolving security threats. A balance between maintaining computer security while enabling user productivity must be considered by IT administrators. While many operating system users run with administrative privileges in both the enterprise and the home, running as an administrator results in a desktop that is hard to manage and has the potential for high support costs. Deploying desktops with standard user permissions can result in cost savings because a non-administrative user no longer has the ability to accidentally or improperly configure the network or install an application that might affect system stability. However, running without administrative privileges is challenging today since many applications fail to run and end users get frustrated by the inability to perform common tasks such as adding printers or changing the local time zone.
Currently, when a user of the Windows operating system, for example, wants to launch a process or perform a task that requires administrative privileges, such as installing an application, the user is prompted by the system for permission or for credentials, depending on the security policy that is chosen (requiring the user to enter the credentials (if the user possesses such credentials) or to have an administrator authorize the task by entering their credentials). Or, if a user wants to run a process that requires more privilege than what they currently have, when they launch the process (such as, in Microsoft Windows™, the “disk defragmenter”, which requires administrative privileges, or any process that requires administrative privileges, debug privileges, backup privileges or more privilege that the user does not currently have), again, the system will prompt the user for additional authentication to launch the requested process.
For example, a user is currently logged into the system. The user would like to launch/run a specific process, e.g., the disk defragmenter—which requires more privilege than the current user has. The system will provide a message indicating that access has been denied, and the operating system will then create a request or “prompt” to the user for increased privilege (by entering the appropriate “credentials”) that will allow the process to launch successfully, or, for a separate set of credentials to launch the process as, essentially, the other user. The prompt to the user may consist of a user interface that presents a question to authenticate using alternate means, such as a user name and password, a smart card, biometric or any other type of credential input, etc. The user must then answer the system's request for higher privilege in order to launch the process, after which the process is launched with the appropriate, higher privilege.
More specifically, in the Windows™ Disk Defragmenter tool, although any user can gain access to the Disk Defragmenter console, the ability to analyze or defragment a volume requires administrator privileges. If the user does not have administrator privileges and attempts to use Disk Defragmentor, he will receive a message indicating that “a user must have Administrator privileges to defrag a volume”. Disk Defragmenter was designed primarily for stand-alone workstations or servers whose users have the ability to log on locally with administrator privileges. Disk Defragmenter was not intended to be a tool for administrators to maintain networked workstations and is not designed to be run remotely and cannot be scheduled to automatically defragment a volume without interaction from a logged-on user. The only way a non-administrator can defragment a local volume is to run the Dfrg.msc console in the context of a user who has administrator privileges.
However, again, the user is prompted for the administrator password. This command may be useful for an administrator who wants to run a defragmentation on a user's computer without forcing the user to log off.
In addition, the concept of least privilege is well recognized in computer security. Essentially, if a task or process is launched by a user having more privilege than necessary to do that task, there is the increased risk that the user may inadvertently do some harm to computer resources. For example, if a set of files can only be deleted by a user with administrator privileges, then an administrator may inadvertently delete those files while performing a different task. If the administrator had been a user having lesser privileges, the intended task could still have been performed, but the inadvertent deletion of files would not have been allowed. As a result, it is not always desirable to provide a user with complete administrative privileges.
Unfortunately, the increasing need for enhanced security often requires the presence of a user to authorize access credentials or other authentication means.
In addition, it is becoming more and more common for processes to operate without a user being physically present at the computer. For example, in an end-to-end automated testing scenario, there is no user present at the machine.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.
An arrangement for programmatically responding to a privilege request on behalf of a user is provided by a trusted entity. More specifically, once the trusted entity is installed, which requires administrative privileges, a local user with standard permissions can pre-configure the trusted entity within the operating system with a list of processes requiring elevated user credentials and a set of user's credentials having such privilege, such that the trusted entity can then programmatically answer security questions presented to the user upon an attempt to launch a process on the list. Upon receipt of the further authentication, the process is launched, then running with the appropriate higher privilege.
In particular, the system service (or “trusted entity”) programmatically responds to privilege requests generated the operating system, eliminating the need for the user to manually authenticate using some type of input mechanism, by acting as an intermediary between a user requesting authorization to launch a process requiring a certain level of privilege (e.g., an administrative action) and the operating system. The system service is used to provide or deny access to any aspect of the operating system for any particular user. The information required to make these decisions is available in a data store that the system service accesses.
More generally, the system service maintains a list of pre-configured “answers” to security questions (e.g., a list of processes that are allowed to run elevated) and has the ability to answer the privilege request from the system programmatically on the user's behalf. In one specific implementation, the process runs as a service in the context of the system. The service has a storage mechanism that may be called the “allowed list”. This list contains information about the processes whose security decisions will be automated by the system service. The information may include process identification, such as the name or a hash of the binary, a set of user's credentials that are known to have enough privilege and rights to run the specific process, etc. The system service also includes an input mechanism that allows users to send the information necessary to configure and query the information in the allowed list.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Additional features and advantages will be made apparent from the following detailed description that proceeds with reference to the accompanying drawings.
The following description relates to implementations of a trusted entity into an operating system, to programmatically drive security decisions presented to a user. The implementation into an operating system is not limited to any particular type of operating system, and may be operating systems provided by Microsoft Corp. under the trade name Windows (e.g., Windows NT®, Windows XP®, Windows 2000®, Windows Vista™). Additionally, the operating system may be an open source operating system such operating systems distributed under the LINUX™ trade name, or a MAC OS® graphical user-interface based operating system, for example. For convenience, however, embodiments are generally described herein with relation to Windows®-based systems. Those skilled in the art can easily adapt these implementations for other types of operating systems or computer systems.
With reference to
A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35 (preferably Windows NT), one or more application programs 36, other program modules 37 and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may 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 personal computer 20, although only a memory storage device 50 has been illustrated in
When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, 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.
The implementation of the privilege automation service is not limited to a Windows operating system, but on the contrary, is intended to operate with and provide benefits with any mechanism that performs security checks at the operating system level.
Again, Windows Vista™, Windows Server® 2003, Windows XP®, Windows 2000™ and Windows NT® are all part of the Windows NT® family of Microsoft operating systems. The architecture of Windows NT is highly modular, and consists of two main layers, a User Mode and a Kernel Mode. Programs and subsystems in User Mode are limited in terms of what system resources they have access to, while the Kernel Mode has unrestricted access to the system memory and external devices. As illustrated in
Kernel Mode in the Windows NT line is made of subsystems capable of passing I/O requests to the appropriate Kernel Mode software drivers by using the I/O manager. Two subsystems make up the User Mode layer of Windows 2000: the Environment subsystem (runs applications written for many different types of operating systems), and the Integral subsystem (operates system specific functions on behalf of the environment subsystem). Kernel mode in Windows 2000 has full access to the hardware and system resources of the computer. The Kernel Mode stops user mode services and applications from accessing critical areas of the operating system that they should not have access to.
More specifically, the User Mode is made up of subsystems which can pass I/O requests to the appropriate Kernel Mode drivers via the I/O manager (which exists in Kernel Mode). Two subsystems make up the user mode layer of Windows 2000: the Environment subsystem and the Integral subsystem.
The environment subsystem was designed to run applications written for many different types of operating systems. None of the environment subsystems can directly access hardware, and must request access to memory resources through the Virtual Memory Manager that runs in Kernel Mode.
The integral subsystem looks after operating system specific functions on behalf of the environmental subsystem. It consists of a security service, a workstation service and a server service. The security service subsystem deals with security tokens, grants or denies access to user accounts based on resource permissions, handles logon requests and initiates logon authentication, determines which system resources need to be audited by Windows 2000, and looks after Active Directory. The workstation service is an API to the network redirector, which provides the computer access to the network. The server service is an API that allows the computer to provide network services.
Windows 2000® Kernel Mode has full access to the hardware and system resources of the computer and runs code in a protected memory area. Kernel Mode controls access to scheduling, thread prioritization, memory management and the interaction with hardware. The Kernel Mode stops User Mode services and applications from accessing critical areas of the operating system that they should not have access to as User Mode processes ask the Kernel Mode to perform such operations on its behalf.
In general, in a Windows operating system for example, a user performs tasks by accessing the system's resources via processes. When a user logs on to the Windows operating system and is authenticated, a security context is set up for that user based on the user's credentials and privileges assigned to that user. For example, an “administrative-level” user may be assigned the privilege that gives the user the ability to set the system clock through a particular application programming interface (API). If however, a currently logged-on user attempts to run a specific process that requires more privilege than the user is assigned, the system creates a request to the user for increased privilege that will then allow the process to launch successfully.
Turning to
With the service installed, a user without any special privilege can use an API to send configuration information to the service. This information contains identification information for the process that will be allowed to run and any information necessary for authentication (e.g., alternate user credentials) that the process may need in order to run. Since this information contains authentication information such as user credentials, the information is stored securely by the service so that the user credentials may only be used by the service.
For example, if a user wants to run the disk defragmenter as “user B”—when the user configures the service, he needs “user B's” user name and password in order to allow the service to actually launch the defragmenter as “user B”. In this way, any user on the system could then launch the defragmenter and it will run as “user B”—i.e., the service will always launch that process as user B. It automates launching that process (that requires more privilege) for all users and allows it so that they can all run it when they may not have been able to run the process beforehand and any security boundary for the privilege request is also automated. In addition, any processes initiated under the user's account have the same privileges as the user.
It should be noted that the privilege automation service can be configured to use one set of credentials for all processes, or specific credentials for each individual process.
Continuing to Step 510, with the service configured, a user then initiates a process launch (corresponding to line “2” of state diagram
Upon receipt of the user's request to launch the process, the operating system (i.e., the security mechanism therein) generates a privilege request to the user (Step 520, corresponding to line “3” of state diagram
Simultaneously, the privilege automation service repeatedly queries the kernel (Step 530, corresponding to line “4” of state diagram
If a determination is made in Step 540 that such a request is waiting for input, the service then checks to see if the process the request is for exists in the list of allowed processes (Step 550, corresponding to line “5” of state diagram
If the process does not exist in the list, the kernel gives the user the opportunity to provide the necessary user credentials, and awaits a response from the user to the privilege request sent to the user in Step 520 (or line “3” of state diagram
If however the process does exist in the list of allowed processes, the privilege automation service then automates the privilege request (Step 560, corresponding to lines “6” and “7” of state diagram
With the privilege request answered, the system then launches the process using higher privilege or a different user (Step 570, corresponding to line “8” of state diagram
Various additional functionalities may be implemented to provide further desired upgrades to a user. For example, the privilege automation service could be configured to allow elevation of an application anywhere between one to N times, or, to always allow elevation of an application, or to never allow elevation of an application. In addition, the privilege automation service could be configured to allow elevation of an application only if the launch is within a predetermined time, for example, within the “next N minutes/hours/days”, or, to allow elevation of the application and then terminate elevation of that application after a predetermined time, or after “N minutes/hours/days”.
The privilege automation service techniques described herein can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment.
For the sake of presentation, the detailed description uses terms like “determine,” and “generate,” to describe computer operations in a computing environment. These terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.
In view of the many possible embodiments to which the principles of the privilege automation service may be applied, we claim all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
