Patent Application
20050091192
Embodiments of the present invention relate to the field of operating systems for computing devices. In particular, embodiments of this invention relate to managing the installation, execution, and removal of application programs by the operating system via application identities.
While current operating systems have made dramatic strides in improving their usability and reliability, further improvements are desired. In particular, the user experience relating to the installation, management, and removal (i.e., uninstallation) of application programs still needs improvement. Many system crashes and hangs may also be attributable to application problems. For example, the following situations may cause an application program and possibly the underlying operating system to fail: an incomplete uninstall of an application, over-deletion when uninstalling an application program, and improperly stored files. For example, during installation an application program may incorrectly configure a system setting or overwrite a file needed by another application program. In addition, it may be difficult for a user to uninstall undesirable application programs such as ad-ware and spy-ware.
In some current operating systems, a newly installed application program may overwrite a shared dynamic-link library (DLL) file with an older or newer version needed by the newly installed application program. If the older or newer file is incompatible with the overwritten file, a currently installed application program dependent on the overwritten file may crash when attempting to access the overwritten file.
While some systems may track the identity of the current user when creating new files, current operating systems lack a mechanism for identifying and associating all the files and system settings associated with the installation of an application program. The operating systems want to recognize the application as there is a need to identify which application the system is acting on behalf of. However, applications may spread themselves across multiple runtime processes, helper utility programs, or system processes doing work for the application. Therefore, the operating systems have difficulties accurately identifying which application a runtime object is working as.
There is a need for a mechanism that allows a system to perform actions consistently for an entire application. Furthermore, operating systems need a means to identify which resources, such as files and system settings, have been created by the operating system itself. As such, the operating system (OS) wants to identify which runtime objects are executing as the operating system as opposed to executing as a non-OS application. Without identifying the OS runtime objects, the system has a hard time restricting only OS runtime object accesses to system objects such as files.
Applications may spread themselves across multiple runtime processes, helper utility programs, or system processes doing work for the app. With applications becoming more important and the system wanting to recognize the application, there is the need to identify which app the system is acting on behalf of. When a new application is installed, or an existing application is upgraded or otherwise adds new files, those files should be marked as having the same application identity as the application of the installed files. In order to build a coherent and comprehensive application identity, there is a need to identify all the files of an application, including executables, dynamic-linked objects, and resources. There is a need for a system that identifies those resources belonging to the application.
Accordingly, an improved system and method for managing application impact is desired to address one or more of these and other disadvantages.
Embodiments of the invention present a general runtime object management strategy which allows an operating system or user to associate runtime objects as a set based on common properties and to configure settings to be applied to the collection of runtime objects. One such property includes the collection of runtime objects that represent an application or operating system. For example, one embodiment of the invention tracks the creation of files associated with an application program.
Another such property enables the operating system to identify itself and to associate the operating system identity with its own files, system settings, and other objects. Further, some embodiments of the invention enable the operating system to recognize which runtime objects are executing as the operating system. Other embodiments of the invention create a security system based on application identity instead of or in addition to user identity.
In accordance with one aspect of the invention, a method tracks creation of one or more files associated with an application program. The method includes detecting creation of a file by an application program. The method also includes determining an identity for the detected file. The method also includes identifying a list associated with the determined identity. The list represents a collection of files associated with the application program. The method also includes adding the detected file to the identified list.
In accordance with another aspect of the invention, one or more computer-readable media have computer-executable components for tracking creation of one or more files associated with an application program. The components include a filter component for detecting creation of a file by an application program. The components also include an identity component for determining an identity for the detected file. The components also include a list component for identifying a list associated with the determined identity. The list represents a collection of files associated with the application program. The components also include a maintenance component for adding the detected file to the identified list.
In accordance with still another aspect of the invention, a method tracks creation of one or more resources associated with an operating system. The method includes determining an identity for an operating system. The method also includes detecting creation of a resource by the operating system during installation of the operating system. The method also includes identifying a list associated with the determined identity. The list represents a collection of resources associated with the operating system. The method also includes adding the detected resource to the identified list.
In accordance with yet another aspect of the invention, a system tracks resource usage and includes a memory area that stores one or more resource lists. Each resource list represents a collection of resources. The system also includes a processor configured to execute computer-executable instructions for detecting creation of a resource, determining an identity for the detected resource, identifying a resource list associated with the determined identity from the one or more resource lists stored in the memory area, and adding the detected resource to the identified resource list.
In accordance with another aspect of the invention, a computer-readable medium stores a data structure for managing access by a collection of objects to one or more resources. The data structure includes a dynamic list of runtime objects. Each runtime object has a common property. The data structure also includes a set of privileges defining access by the runtime objects to at least one resource.
Alternatively, the invention may comprise various other methods and apparatuses.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
In an embodiment, the invention includes assigning a unique identity to each application program or other software product installed or to be installed on a computing device. In particular, the invention includes assigning an application identity to the application program and a resource identity to each resource created or associated with the application program. A resource includes, but is not limited to, a file, folder, process, thread, system setting, named object, an application programming interface (API), a specific code path, a library of executable routines, operating system property value, and an operating system resource. For example, a number of APIs and code paths provide send mail capability, and access to these APIs and code paths might be restricted. In another example, the ability to reboot the system is restricted. Resources also include the system's name space (e.g., the ‘names’ themselves), not just specific named objects. For example, reserving or ‘squatting’ on a name before an object is created with the name creates both fragility and security issues.
The assigned application identity differentiates the application program from other application programs. An embodiment of the invention relates the application identity and the resource identity to enable safe manipulation, extensibility, and integration of the application program and its resources with the operating system. The application identity and resource identity provide uniqueness, consistency, and persistency (i.e., a non-evolving identity). Generally, an application identity and resource identity may be explicitly defined by an application manifest or other metadata or may be derived from attributes of the application. In one embodiment, the application identity and the resource identity are the same.
Similarly, the invention identifies resources that belong to the operating system. The operating system identity may be explicitly reserved or defined in the operating system manifest or from metadata, or derived during OS execution or installation (e.g., from an installation program).
Various benefits are achieved by identifying an application program and its resources. For example, identifying each application program enables users to undo any changes made to a computing device because the changes made by each application program (e.g., interactions with the computing device and resources) are persisted and logged. Further, identifying each application program and its associated resources enables the user to fully remove (e.g., uninstall) the application program and undo any changes made by the application program to the computing device resources.
In another example, identifying each application program installed or to be installed on a computing device enables the operating system to protect vital resources from accidental or malicious modification by an application installer. The application identities and operating system identity improve the consistency and reliability of the underlying operating system. The invention may also be combined with other protection strategies such as read-only access, isolation, virtualization, change tracking, and sandboxing to provide further protection.
The description, figures, and examples herein are not limited to any specific operating system. Rather, embodiments of the invention may be applied to an operating system of any type, model, and configuration. Further, embodiments of the invention are not limited to any of the exemplary methods described herein for assigning identities. Rather, embodiments of the invention are applicable to any method or design for uniquely identifying an application program and its associated resources, as well as identifying the operating system and its associated resources.
Determining and Storing an Application Identity
Referring first to
The flow chart in
At 106, the invention associates the installation program with the application identity either automatically via the installation program, the system, or manually via the user. Hence, the files created by the installation program and the threads doing work on behalf of the installation program receive the application identity. The invention also associates the application identity with a process launched from an image file and across interprocess communication (IPC) mechanisms (e.g., via a security token or directly with the transport).
In an upgrade example, the installation program is already aware of the application identity from the original installation process and propagates the application identity to the files that it updates. If the update arrives as a separate installer package, the installation program determines the application identity assigned to the original installation and registers the determined application identity for the separate installer package.
For the pre-assigned application identity embodiment, the operating system is configured to scan the deployment package of an application program. A unique signature is then produced from the scan (e.g., by using a hash). The unique signature is used to establish a link with a pre-assigned application identity. In one embodiment, the hash includes a sufficiently strong hash to render it probabilistically unlikely that the hash of any two files creates the same signature.
In some embodiments, the application identity is created by the application developer and is stored in an application manifest. The manifest accompanies the application program when the program is installed. The method determines an application identity from the manifest (e.g., included in a software distribution package) by locating and extracting information specific to the application program. The invention extracts and stores the metadata to determine the application identity for the application program to be installed. In one example, application identity is generated from a strong name by hashing the name and the PKH fields. In this embodiment, the manifest is a declarative source of the application identity.
If no metadata from these sources exists, embodiments of the invention identify the application program by generating a non-declarative application identity. The method generates the application identity information at 110 (including an application identity at 112) when the installation process begins if the application program does not have an assigned application identity (e.g., an application without a manifest or other predefined mechanism). This may be accomplished by locating and extracting specific information about the application program from the installation package (e.g., vendor, product name, product version, and module checksum). For example, an application suite with a number of different applications may be installed from a single installation program. The installation program may be configured with a single application identity that is applied to all programs installed from the single installation program. In a specific example, a business productivity suite may include an electronic mail program and word processing program, but the installation program may be configured to apply the same application identity to each application being installed because both programs are from the same application suite. In another embodiment, the installation program generates comparable identity information from the software product footprint. For example, different versions of the same application will have a different footprint, resulting in different application identities. In yet another example, a setup file (e.g., setup.ini) may be part of the software product deployment package. The setup.ini file includes information for an installation bootstrapper component (e.g., setup.exe) to perform. A property such as AppName in a specific section (e.g., Startup) of the setup.ini file may include the name of the product. In another example, file version information resources may include entries such as CompanyName and ProductName. The values for these entries are used as product vendor and product name attribute values. The information is extracted with functions such as GetFileVersionInfo( ) and VerQueryValue( ). In an example in which the application identity data structure stores sixteen bytes, the first half of the structure stores hash values generated from the identified vendor name and product name.
The determined and generated identity information is stored (e.g., persisted) at 114 for future use (e.g., by the underlying operating system). For example, the identity information is stored in the runtime objects (e.g., processes, threads, context objects, tokens, and runtime contexts) or a container object.
Determining the Components of an Application Program
Application programs include computer programs or pieces of software designed to perform one or more specific tasks or functions. An application program as perceived by a user may actually be a collection of components including, but not limited to, executable modules, dynamic libraries, resources, and supplementary files logically or functionally grouped to perform the set of specific tasks. The components may be bound together explicitly and implicitly to form the application program. Some of the components of an application program may have a hard dependency on each other. Some application components may be shared with other applications. The application program may have routines imported from other modules during a process referred to as “binding.” For example, in a portable executable file format, an import section defines the routines, modules, variables, and other symbols the loader should locate and link to create the application program. In another example, references to all the external assemblies used by the application program are listed in a manifest included within an assembly dynamic-link library (DLL) or supplied externally to service multiple DLLs.
Implicit dependencies are typically not regulated by any data structure within file formats. One module may depend on a symbol exported from another module, but the binding happens in runtime when a host module dynamically loads the other module. For example, a host module requests creation of an object instance and requests a reference to the module which provides the implementation for the object. In another example, a component may rely on data stored within a non-executable file such as a bitmap, an icon, video, and sound.
Embodiments of the invention include methods for identifying the explicit and implicit module dependencies to enable identification of an application program in various ways. Typically, the components that form an application program are grouped together by the application vendor into one deployment package. The methods include using the deployment package to track the files created and system settings stored during installation to identify the files belonging to a specific application program. The methods assign an identity to each of the files created by the application. The identity is associated with the application identity of the application program as illustrated in
Isolation Identities
In some embodiments, an isolation identity is assigned to an application program in addition to an application identity by an operating system component (e.g., a group component) according to the invention. While the isolation identity may be associated with just this application, the isolation identity may also be associated with another application program having another application identity associated therewith. The isolation identity may be used to logically group application programs with different application identities. In general, the application programs may have a common context (e.g., installed by a particular user). For example, if two application programs from the same application suite have different application identities, the operating system assigns the same isolation identity to both application programs. Some or all of the information gathered to generate the application identities may be used to group the applications into isolation identities based on analogous characteristics. For example, embodiments of the invention may use the vendor name, product name, and/or a signature of the binary content of the module to generate the isolation identity.
In general, an isolation identity is generated by obtaining module metadata or other attributes. Based on the type of the module and functional designation there are various ways for the module vendor (e.g., developer) to associate metadata with the module. The metadata may be part of the physical file representing the module or stored in a separate file or files.
The application programs assigned to a specific isolation identity create a virtual program group. All application programs in the virtual program group receive the equivalent virtualized view of the operating system (e.g., the same level of access to system resources). That is, different applications with the same isolation identity share the same virtualized view of the system. In an example in which different versions of the same application program are assigned different application identities, the different versions may be assigned the same isolation identity because the different versions are to receive equivalent access to system resources.
An operating system provides access control for its resources via the application identities and/or groups of application identities (e.g., isolation identities). An application group includes one or more application identities. Isolation identities serve as a specific type of application group. For example, the operating system may maintain multiple copies and/or versions of the same file (e.g., virtual copies) with potentially different access rights with respect to an application. The operating system dynamically virtualizes a file requested by an application program with a specific isolation identity for write access. In one embodiment, all products from different vendors and different products from the same vendor have different virtualized views while all versions of the same product from the same vendor share the same virtualized view. The comparison of the vendor names and product names may be based on the case insensitive string values for the vendor name and product name attributes.
Referring next to
In operation, a component of an operating system 202 according to an embodiment of the invention (e.g., a virtualization component) receives a request from application program ID1 for File A. In one embodiment, the request includes the assigned identity ID1 and IsoID1. In other embodiments, the operating system 202 infers the assigned identity ID1 and IsoID1 or queries the application program ID1 for the assigned identity ID1 and IsoID1. Responsive to the received request, the operating system 202 determines whether a particular version of the operating system resource exists for the application program based on the received identity. In this case, the copy 204 of File A exists for the identity IsoID1. The operating system 202 provides the application program ID1 with the copy 204 of File A exists for IsoID1. If the copy 204 of File A for IsoID1 did not exist, the operating system 202 would generate the copy from original File A and provide the generated copy to application program ID1.
Generating the Application Identity and Isolation Identity During Runtime
Referring next to
Alternatively the application and isolation identities may be determined over time by observing the behavior of an application to determine the resources used, and then performing subsequent computations to determine the appropriate identities to use for the application (or a group of observed applications) according to system criteria such as minimizing sharing or restricting accesses. Furthermore, the application and isolation identities of an application may be modified over time by the system as new behaviors are determined and analyzed. Behavioral determination of identity is useful in one example where there is insufficient information regarding an application, yet an identity is desired for security purposes. By analyzing application behavior in an interval where the system is not believed to have been successfully attacked, behaviors for an arbitrary application can be determined that allow construction of an identity which restricts the behaviors of applications in the future (e.g., when the application might be successfully attacked).
The application identity and the isolation identity may be combined to form an identity context associated with an application program or a module therein.
Application Identity Data Structures
The identity tag for a module or component persists the application's identity context. The identity context may also include one or more flags to store additional information such as attributes associated with the methods of generating the application identity and the isolation identity. For example, the flags may include an installer bit that indicates that the metadata used to generate the application identity and the isolation identity was extracted from a module identified as a known installer.
Referring next to
In one embodiment, the identity tag for a file or other component includes a creator context formed during creation of the file (e.g., CreateFile( )) and a revised context formed during process creation (e.g., CreateProcess( )). The file tag may only have a creator context until process creation for the file during which the identity is elaborated or revised.
Referring next to
Revising the Identity Context During Process Creation
Referring next to
When a user executes the module, embodiments of the invention determine if there is a creator identify context associated with the module. If there is a creator identity context, the identity context is elaborated to create a revised context and persist it in the tag. The revised identity context is associated with the run-time data about the module stored, for example, by the operating system.
If an identity tag does not exist for the module, embodiments of the invention determine an identity and form the creator context and the revised context. The created identity context is persisted in the file's tag for future execution of the module.
Revising the identity context includes using heuristic algorithms and checking signatures with a pre-populated library of application identities (e.g., inherited identity context). Further, elaboration methods include analyzing the revised context of the parent process, the creator context of the module (e.g., File A), and the module itself (e.g., File A) to generate the revised context of the module. In one example, the creator context for the module is copied into the revised context if the module does not have a declarative identity. In another example, the value for the revised context is derived from the module or metadata if the module has a declarative identity.
In an alternative embodiment, a generic system utility executes without an identity but derives an identity from the first non-system library that it loads.
Referring next to
If the module is not a known shared installer engine at 716, but the module's identity context has a “created by installer” flag at 728, the method forms the revised context from the creator context at 730. If the module's creator identity context does not have a “created by installer” flag at 728, the method forms the revised context from the module metadata at 726. The method returns the revised identity context for the new process at 732.
In one embodiment, the assigned identity context for a module may be tagged for re-assignment. A subsequent attempt to create a process on the module prompts an embodiment of the invention to generate and assign a new identity. In another embodiment, information is persisted to enable reverse-engineering and disaster recovery of the file/process creation hierarchy. Such information may include a system-wide cache of each module and its identity tag. In yet another embodiment, a manifest is automatically generated and updated with identity context data for each module.
Identity Context Impersonation
In some cases it may be useful to allow the operating system or an application to temporarily impersonate another application. For example, it may be desirable to have a server-based installation program temporarily impersonate the application identity of a client resident installation program so that the installed application will appear to have been installed from the client. The use of impersonated application identities allows a thread or process to execute with the identity context of another application. Embodiments of the invention may be configured to provide a runtime service (e.g., an impersonation component) to transition an application identity from one application to another. The runtime service enables an application to acquire the identity of another application for performing work on behalf of an application after the completion of which the original identity is restored. Access control may be implemented to enable only selected application programs to impersonate other application programs. For example, the requestor's rights are checked against a security descriptor of the target process or token.
Embodiments of the invention also provide implicit impersonation. For implicit impersonation, the system overrides the identity contexts obtained from the identity tag and assigns different contexts based on other information about the process module. For example, a parent process instantiates an object within the context of the local server. The server thread is assigned the same identity context as the parent process that initiated the object instantiation. An example of explicit impersonation includes the known shared installer engine assigning the identity of a parent “bootstrapper” process to itself.
Application Security Identity
Embodiments of the invention grant security rights to an application by associating the rights with the application's identity and the identity of the user that is running the application. Application-specific security rights can be associated with a running application by adding an application-specific Security ID (APP-SID) to the security token associated with processes and services that execute on behalf of the application. Access control lists (ACLs) associated with operating system objects (including but not limited to files, ports, memory, processes, threads, and system services) include access rights with respect to APP-SIDs as well as security identifiers for users.
With the invention, the access checks in a security monitor of the invention consider multiple SIDs when deciding to grant access. In previous systems there was only the single SID belonging to the user. APP-SIDs introduce at least one new SID to compute against the access rights granted by the ACL. And in some embodiments, an access request may have more than one APP-SID associated with the request.
The embodiment of APP-SIDs in a typical security monitor interpret multiple SIDS in one of several ways as specified by the ACL itself: grant access according to the intersection of privileges of all the SIDs presented (e.g., the least common) or grant access according to the union of the access rights of the SIDs.
Computing the intersection of the SIDs may occur when a user has access to an object, but does not want to grant that access to an application. Alternatively, computing the intersection of the SIDs may occur when an application has access to an object but doesn't want to grant access unless the user (or all other applications) also has access. One use of intersection restricts the access of an application downloaded from the network so that it only has access to certain files that are accessible by the user.
Granting access according to the union interpretation allows an application to acquire additional access that the user may not possess. In one such use, a user may not have access to a system service to change the date in the system clock. But the user may have access to a service which has an APP-SID that does allow the date to be changed. The advantage is that the accessible service provides more limited functionality than the underlying service for changing the date, such as only allowing date changes that fall within a limited range. APP-SIDs allow such intermediate service to be written.
Some embodiments use other combinations of access checks, such as respecting the DENY Access Control Entry (ACE) in an Access Control List to deny access even if GRANT access is computed by union. Other embodiments may treat application and user SIDS differently, using the GRANT/DENY ACEs associated with an APP-SID to grant or deny additional privileges to a user's SID with respect to an object.
In another embodiment, the application identity may also be used to associate generalized privileges (e.g., capabilities) with an application. Capabilities differ from ACL-based security in that a capability is not checked against an access list associated with an object but is instead explicitly checked for by code in key system paths. For example, a capability (e.g., send mail) may be associated with an application. There is no specific object associated with sending mail, but there are a number of code paths that may be used to send mail. Each code path checks for the privilege of the application to send mail before permitting the application to execute the code path.
Servicing Applications Based on their Application Identity
Application identities and isolation identities provide a framework to manage the manner in which an operating system provides services to applications that are installed on the system. The services may be provided based on application identities or groups of application identities (e.g., an isolation identity). An embodiment of the invention uses a storage system for the application identities and/or the isolation identities along with an application programming interface (API) that provides access to the identity information during runtime. Depending on the implementation, the service provider may be able to acquire the identity of the application to be serviced regardless of the runtime state (i.e., whether the application is running or not) to perform the actions over the application processes or the files or resource set belonging to the applications.
Next, some potential benefits of the features described herein are discussed. While these are potential benefits, actual implementation and selection of particular features will dictate which of these advantages, if any, are associated with a particular implementation. Software application identities allow the system to recognize an application as one entity and provide services to it. Determining and assigning non-declarative identities enables the operation system to automatically recognize every application installed and to be installed on the system. The precise and reliable identification of the software deployment package is important for early detection and population of the identities of the application programs associated with the package. The concept of providing services to the application expands and generalizes the software administration process from the servicing of different applications each with individual activities to the common set of actions from the operating system toward the software loaded. Within a scope of the application identity framework, each application has its own identification information. There is a class of tasks to be performed by one application on behalf of another. The most typical example is administration and maintenance. Embodiments of the invention allow the administrative tools and utilities to impersonate the serviced application.
General Runtime Object Management
A set denotes a container object which contains runtime entity members, such as processes, threads, and other sets. The members of a set share an intrinsic property such as all runtime objects belonging to an application, a logon session, or by some user-defined rule. For example, member processes may include all the processes in an application, administrator-defined group, operating system group, or another group. In one example, the set may be associated with an application identity. Set objects may be namable, securable (ACLs), and sharable.
A runtime object or other runtime entity may join multiple sets, and a set may join another set. For example, an application suite of products may define a set per product and create a set, representing the application suite, which contains each of the products' sets. A utility program process, used by the application suite to launch each product, may be a direct member of the application suite's set but not necessarily a direct member of the individual product sets.
In one example, the operating system joins the objects or members to the set (e.g., in a specific order to allow deterministic traversing of the members). Processes may be manually or automatically added to a set. For example, a new child process of a parent process belongs to the set of the parent process if the set has an inheritance property enabled. A process may also automatically join a set if the executable image file of the process has an application tag containing an application identity associated with the set. In another example, an object doing work on behalf of another application joins the set of the other application (e.g., during interprocess communication tasks, thread pools, or work items). In one example, a user (e.g., an administrator) adds a process to a set through a user interface of an operating system component or application program for monitoring or isolation. In other embodiments, an application program or the operating system component directly adds the process to the set.
An object may also disjoin from a set if permitted by the attributes on the set. For example, an object may disjoin from a set associated with an application if the object stops doing work on behalf of the application. Processes that are set members may disjoin from the set without process termination. In one embodiment, the ability to disjoin is a configurable property of the set. For some types of sets, the process should not be able to disjoin (e.g., if there are security decisions made based on membership in that set).
A computer-readable medium stores an exemplary data structure for a set. The exemplary data structure includes a dynamic list of runtime objects where each runtime object has a common property. The exemplary data structure also includes a set of privileges defining access by the runtime objects to at least one resource. The set of privileges may include, but is not limited to, one or more of the following: rules, properties, attributes, authorized actions, and unauthorized actions. The set of privileges may be stored on each of the runtime objects or in a manifest (e.g., an extensible markup language manifest) associated with an application program.
Each member in a set has a designation (e.g., stored in a property field) of how the member joined the set. The designation includes, for example, child creation inheritance, work item inheritance, or explicit membership. Child creation inheritance represents members that join the set due to the inheritance attribute when a parent object creates a child object. Work item inheritance means the runtime object is performing work on behalf of another runtime object. In this example, set memberships may propagate across communication networks for client-server models for the duration of the work item. To illustrate, a client program process contacts a server process to perform a work item. Then, the server threads that receive and process the request temporarily join the inheritance sets of the client context until the work is completed. Explicit membership denotes that a user or program manually added the runtime object to the set. Specialized set types may specify custom designations for particular needs.
Exemplary property fields in a set include a Set Inheritance field for designating whether new child processes automatically join the set, a Set Type field for identifying a set type for the set, and a Set Identifier for runtime differentiation between sets. A set may have one or more of the set types. The operating system may define standard set types for each of the intrinsic properties available for a set, and allow the user and applications to define custom set types. For example, a group set provides a view of all current descendant processes started by initial set members. The user adds processes to a group set, for example, to collectively monitor or suspend them with their own mechanisms. In a tagging set example, the initial tagged executable launches and joins a tagging set. Any data files or image files launched by the initial tagged executable are also tagged and join the tagging set. In a security set example, processes are added to the set according to users or groups. The security sets is audited for various operations like file, network, and registry. In one example, each user's processes are added to a security set to enable termination of the processes collectively when the user's account is disabled. Further, each of the security sets may be added to a single, master security set to enable collective termination of all user accounts associated with the security sets. In a resource management set example, all members have their resources usage controlled by a resource manager. In a Terminal Server session set example, various Terminal Server session sets are joined into a master Terminal Server session set to enable resource tracking across all the Terminal Server session sets.
The Set Identifier enables sets to be differentiated from each other. In an example in which multiple copies of an application are executing, the Set Identifier helps determine, for example, which parent copy spawned a new helper process and helps associate the new process' actions with the parent's actions.
The set allows monitoring and collective actions on all its members such as suspend, terminate, control/audit resource consumption, virtualize resources, query membership, add/remove member, query/set intrinsic property, query/set set type, etc. The operating system and other components may define other actions to take on a set. The system may act upon a set uniformly and issue actions on the set which propagates the actions to its member objects. For example, actions include querying for information about the set, configuring the set, terminating set elements, and suspending or resuming processes in the set. Querying for information about the set includes querying about basis set statistics (e.g., a list of process members or a list of child Sets), collective resource usage (e.g., CPU, I/O, memory), set properties, and Set Type. A list of a runtime object's set memberships may also be obtained. Configuring the set includes specifying the set properties, Set Type, and resource usage limits.
The operating system may also control the security of the set via ACLs so that only the appropriate entities may perform accesses on a set. For example, a user's finance documents may only be accessible to a particular finance application instance running with that user's account (e.g., having proper intersection semantics). In this example, a virus program executing in the user's context cannot gain access to the user's finance documents. Permission may be explicitly given to other authorized applications or groups of applications.
Application Runtime Identification Using Sets
Sets provide a convenient way to identify all the runtime objects belonging to the application as well as the runtime objects performing work on behalf of the application. The system creates an application set type and sets the intrinsic property as the application identity value.
As an application is launched, the operating system retrieves the application identity for the application image and opens or creates the application set that has the application identity as the intrinsic property. The operating system adds the newly created runtime object, such as the process object, to the application set. The application set may have a special designation in this case to denote that the member joined the set via application launch. The new runtime object inherits its parent's sets as appropriate.
Referring next to
In a particular example, the method receives a request from the runtime object for access to a resource and determines an identifier associated with the runtime object at 810. The method further identifies a set associated with the determined identifier and determines one or more attributes associated with the identified set at 812. The method provides access to the requested resource as a function of the determined attributes at 814. Determining one or more attributes may include determining a security profile associated with the identified set, determining an access control list associated with the identified set, or determining a list of capabilities associated with the runtime object 904. For example, the method may compare the received request to the list of capabilities and provide access to the requested resource as a function thereof. In one embodiment, the method prompts a user to alter at least one of the one or more attributes and provides a user interface to a user for creating the one or more attributes.
In one embodiment, one or more computer-readable media have computer-executable instructions for performing the method illustrated in
Referring next to
The system of
Components that want to determine which runtime objects 904 belong to an application open the application set with the target application identity and query its members. The caller may choose to distinguish the members between their designation: inheritance or explicit. Inversely, components may determine which applications a runtime object 904 is running as. The caller queries the runtime object's set membership and filters for the application set type. Components may further distinguish the set membership via the join designation.
Identifying the Files of an Application for Application Identity
Identifying the files belonging to an application serves an important role since applications typically launch their specific computer-executable instructions from files such as executables, dynamic-link libraries (DLLs), and resources. In order to identify the application's files when the application does not declare which files belong to it, the operating system may track the file creations performed by an application and associate those files with the application.
Referring next to
In one embodiment, the method distinguishes between creation of a user file and creation of an application file. Further, in another embodiment, one or more computer-readable media have computer-executable instructions for performing the method illustrated in
One means of discovering the application's files involves monitoring application file creations with a file system filter driver. For example, when an application installation process starts, the OS determines the installed application's identity and adds the process to the associated application set. The file system filter driver looks up the process' application identity. As any runtime object member of the application set creates a file, the file system filter driver associates the file with the application so that subsequent runtime objects launching from the file also join the application set.
In another embodiment, the filter driver depends on an identity already associated with the process. This identity is assigned when an application installer goes through CreateProcess( ). The filter driver detects creation of a new file and determines which runtime object (e.g., the application installer) issued the create call. The filter driver queries the identity of the determined runtime object and assigns that identity to the create file.
An exemplary implementation of a driver according to the invention is shown in
In one embodiment, the driver 1102 is implemented as one or more computer-executable components stored on one or more computer-readable media. The components include a filter component 1112, an identity component 1114, a list component 1116, and a maintenance component 1118. The filter component 1112 detects creation of a file or other resource by an application program 1106. The identity component 1114 determines an identity for the detected file. The list component 1116 identifies a list such as list 1104 associated with the determined identity. The list 1104 represents a collection of files associated with the application program 1106. The maintenance component 1118 adds the detected file to the identified list 1104.
The invention distinguishes between user files created by the application and application files created by the application. To illustrate, a word processing application installs application files which it needs for execution. Yet, the same word processing application creates document files on behalf of the user. The operating system may provide services, such as backup, where the user document files should get backed up, but not the application's files. Conversely, the user might want their user document files skipped by some operating system services like application uninstall or application resource virtualization. In one embodiment, the invention identifies all files created as part of an installation or an update as application files because those file creations are most likely to be files needed for application execution. Alternatively or in addition, the invention may differentiate between user files and application files by examining the file format (e.g., the header), file extension, or the application program assigned to open that type of file. For example, the operating system may heuristically distinguish the files by observing the shell file type registrations (e.g., .doc is associated with a word processor).
Ultimately, the application knows best which file creations get performed on behalf of the user. Thus, application identity aware application program may cooperate with the operating system to denote that a particular file creation is for a user file. Every other file creation gets treated as an application file.
Without application cooperation, the operating system may attempt to distinguish between user files and application files by monitoring application installation and/or updating runtime objects, which the operation system treats as application files. Other file creations performed by application get treated as user files. Possible other identifying metadata include, but are not limited to, file extensions, existence of a code module header, and file system path.
Identifying System Components and Associated Resources
Often components need to determine whether a particular runtime object belongs to the operating system and which resources were created by the operating system. For example, the operating system has specific resources that should be restricted for access by operating system components. Applications should not be able to access those resources.
To determine the resources belonging to the operating system, the operating system may explicitly declare its resource ownership in a manifest, pre-populate the association database with identification information for the resources belonging to the operating system, directly sign its resources, store its resources in protected locations, or monitor the resource creation performed by the operating system installer. In other embodiments, the operating system may inventory the installed resources after completion of the OS installation and before any applications have installed. Other techniques for monitoring the operating system installer are contemplated.
For example, in one embodiment of the invention, an operating system assigns a system application identity to its system files. The operating system installer associates the system application identity with the files that it installs. Since the application identity of the operating system may require more access than an application acquires, the operating system application identity is guarded. In one embodiment, the application identity used to denote the operating system is reserved and restricted for assignment by only privileged operating system components. Having the system application identity enables the operating system to distinguish between its files and those files belong to other, non-OS applications.
Operating systems may wish to further distinguish between components of the operating system. This granularity allows the operating system to protect individual components from other operating system components.
Capabilities-Based Security
By having a runtime application identity and recognizing which files belong to the application, the system may attempt to protect objects based on application identity. The system may utilize application identity in addition to user identity to protect objects.
For example, an application may decide that it wants to restrict access to its temporary files to itself. Thus, the application sets the security on the file to allow only the application sole access to the file. When a different application tries to open the original application's temporary file, the system denies the request.
In another example, a finance application may decide that access to the user's finance documents should be restricted to just that user and also to that application. In this manner, a virus program running in the user's context in a different application lacks access to the user's finance documents. If other finance applications need access to the user's finance documents, the original finance application may explicitly grant access to specific applications or to a group of finance application identities. In another embodiment, the user may be prompted with “X app is trying to access your sensitive financial docs, should we allow once, deny once, allow always, or deny always?”
In yet another example, the system allows the user and application publisher to define actions that the application may perform (e.g., access user personal documents or access the network). The system components monitoring or performing the actions check whether the application has been granted access to that capability. If the application attempts to perform an action for which it lacks access, then the system responds appropriately. The system may reject the attempted action or notify the user of the attempt and confirm whether the application should be granted access to that capability.
In one embodiment, the user defines which application publishers should be trusted to specify application capabilities. Therefore, a malicious program will likely not have a trust application publisher, thus the user rejects certain application's action requests due to the untrusted or unknown application publisher.
The system of the invention attempts to expand existing security systems beyond user level granularity (e.g., per ACLs) into a more user-understandable system of application actions which the system of the invention enforces.
Exemplary Architecture
Referring next to
In
Exemplary Operating Environment
The computer 130 typically has at least some form of computer readable media. Computer readable media, which include both volatile and nonvolatile media, removable and non-removable media, may be any available medium that may be accessed by computer 130. By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by computer 130. Communication media typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of the any of the above are also included within the scope of computer readable media.
The system memory 134 includes computer storage media in the form of removable and/or non-removable, volatile and/or nonvolatile memory. In the illustrated embodiment, system memory 134 includes read only memory (ROM) 138 and random access memory (RAM) 140. A basic input/output system 142 (BIOS), containing the basic routines that help to transfer information between elements within computer 130, such as during start-up, is typically stored in ROM 138. RAM 140 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 132. By way of example, and not limitation,
The computer 130 may also include other removable/non-removable, volatile/nonvolatile computer storage media. For example,
The drives or other mass storage devices and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into computer 130 through input devices or user interface selection devices such as a keyboard 180 and a pointing device 182 (e.g., a mouse, trackball, pen, or touch pad). 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 132 through a user input interface 184 that is coupled to system bus 136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a Universal Serial Bus (USB). A monitor 188 or other type of display device is also connected to system bus 136 via an interface, such as a video interface 190. In addition to the monitor 188, computers often include other peripheral output devices (not shown) such as a printer and speakers, which may be connected through an output peripheral interface (not shown).
The computer 130 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 194. The remote computer 194 may be a 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 computer 130. The logical connections depicted in
When used in a local area networking environment, computer 130 is connected to the LAN 196 through a network interface or adapter 186. When used in a wide area networking environment, computer 130 typically includes a modem 178 or other means for establishing communications over the WAN 198, such as the Internet. The modem 178, which may be internal or external, is connected to system bus 136 via the user input interface 184, or other appropriate mechanism. In a networked environment, program modules depicted relative to computer 130, or portions thereof, may be stored in a remote memory storage device (not shown). By way of example, and not limitation,
Generally, the data processors of computer 130 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 a computer. At execution, 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 herein.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, 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.
Although described in connection with an exemplary computing system environment, including computer 130, the invention is operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
An interface in the context of a software architecture includes a software module, component, code portion, or other sequence of computer-executable instructions. The interface includes, for example, a first module accessing a second module to perform computing tasks on behalf of the first module. The first and second modules include, in one example, application programming interfaces (APIs) such as provided by operating systems, component object model (COM) interfaces (e.g., for peer-to-peer application communication), and extensible markup language metadata interchange format (XMI) interfaces (e.g., for communication between web services).
The interface may be a tightly coupled, synchronous implementation such as in Java 2 Platform Enterprise Edition (J2EE), COM, or distributed COM (DCOM) examples. Alternatively or in addition, the interface may be a loosely coupled, asynchronous implementation such as in a web service (e.g., using the simple object access protocol). In general, the interface includes any combination of the following characteristics: tightly coupled, loosely coupled, synchronous, and asynchronous. Further, the interface may conform to a standard protocol, a proprietary protocol, or any combination of standard and proprietary protocols.
The interfaces described herein may all be part of a single interface or may be implemented as separate interfaces or any combination therein. The interfaces may execute locally or remotely to provide functionality. Further, the interfaces may include additional or less functionality than illustrated or described herein.
In operation, computer 130 executes computer-executable instructions such as those illustrated in the figures to determine and assign application and isolation identities to enable the management of a plurality of applications on a computing system.
The order of execution or performance of the methods illustrated and described herein is not essential, unless otherwise specified. That is, elements of the methods may be performed in any order, unless otherwise specified, and that the methods may include more or less elements than those disclosed herein.
When introducing elements of the present invention or the embodiment(s) thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained.
As various changes could be made in the above constructions, products, and methods without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
| Number | Date | Country | |
|---|---|---|---|
| 60513941 | Oct 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10938126 | Sep 2004 | US |
| Child | 10963479 | Oct 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10868183 | Jun 2004 | US |
| Child | 10938126 | Sep 2004 | US |
