Source: http://www.google.com/patents/US8181219?dq=patent:5992892
Timestamp: 2014-08-21 18:48:48
Document Index: 99319826

Matched Legal Cases: ['Application No. 2005209678', 'Application No. 2005209678', 'Application No. 200510108862', 'Application No. 200510108867', 'Application No. 200510108867', 'Application No. 200510108867', 'Application No. 05108532', 'Application No. 05108532', 'Application No. 05108532', 'Application No. 05108704', 'Application No. 05108704', 'Application No. 05108704', 'Application No. 05', 'Application No. 2005', 'Application No. 2005', 'Application No. 2005290091', 'Application No. 10', 'Application No. 05108532', 'Application No. 200510108867', 'Application No. 200510108867', 'Application No. 05108532', 'Application No. 05108532', 'Application No. 05108532', 'Application No. 2005209678', 'Application No. 05108704', 'Application No. 2005130458']

Patent US8181219 - Access authorization having embedded policies - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA facility for receiving an embedded policy is provided. The facility checks an application program image for the presence of an embedded policy. If an embedded policy is detected, the facility extracts the policy from within the application program image. The facility may then apply the extracted policy...http://www.google.com/patents/US8181219?utm_source=gb-gplus-sharePatent US8181219 - Access authorization having embedded policiesAdvanced Patent SearchPublication numberUS8181219 B2Publication typeGrantApplication numberUS 10/956,667Publication dateMay 15, 2012Filing dateOct 1, 2004Priority dateOct 1, 2004Also published asCN1808325A, US8453200, US20060075462, US20110126260, US20120036554, US20130254835Publication number10956667, 956667, US 8181219 B2, US 8181219B2, US-B2-8181219, US8181219 B2, US8181219B2InventorsGilad Golan, Mark VaymanOriginal AssigneeMicrosoft CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (58), Non-Patent Citations (89), Classifications (9), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetAccess authorization having embedded policiesUS 8181219 B2Abstract A facility for receiving an embedded policy is provided. The facility checks an application program image for the presence of an embedded policy. If an embedded policy is detected, the facility extracts the policy from within the application program image. The facility may then apply the extracted policy to the application program image before the application program image is loaded and/or executed. Moreover, the facility may check the application program image's integrity prior to extracting the embedded policy.
1. A method in a computing system having a memory and a processor for receiving an embedded policy, the method comprising:
receiving a request to load a first application program of a first application program image;
determining whether a first policy is embedded within the first application program image, such that the first application program image contains the first application program and the embedded first policy, wherein the first policy is coded in a programming language;
responsive to determining that a first policy is embedded in the first application program image:
with the processor, extracting the first policy from the first application program image,
loading the first application program for execution by the processor,
starting execution of the first application program,
with the processor, intercepting a call by the first application program to access a resource, and
upon intercepting the call,
with the processor, executing the code of the extracted first policy to determine whether to allow or deny the access,
upon determining that the access is allowed, enabling the access, and
upon determining that the access is not allowed, preventing the access
so that the first application program of the first application program image is restricted from accessing computer resources in accordance with the access restrictions defined by the first policy embedded within the first application program image;
embedding a second policy within a second application program, wherein the second policy defines access restrictions for the second application program, so that the second application program contains the embedded second policy;
accessing a directed graph that represents system calls normally issued by the second application program, wherein the directed graph was previously generated by tracking previous instances of the second application program;
tracking the execution of a second instance of the second application program; and
upon detecting, based on the tracking and the directed graph, an anomalous condition in the execution of the second instance of the application program,
extracting the embedded second policy from within the second application program, and
applying the extracted second policy to the second instance of the application program
so that the second instance of the second application program is restricted from accessing computer resources in accordance with the access restrictions defined by the second policy that is embedded within the second application program.
responsive to determining that a first policy is not embedded in the first application program image:
when a third policy applicable to the first application program is stored in a policy repository,
loading the first application for execution on the computer, and
applying the third policy applicable to the first application program that is stored in the policy repository so that the first application program is restricted from accessing computer resources in accordance with the access restrictions defined by the third policy applicable to the first application program that is stored in the policy repository, and
when a third policy applicable to the first application program is not stored in the policy repository, not loading the first application program for execution on the computer.
3. The method of claim 1, wherein the embedded first policy is declared using XML.
verifying the integrity of the first application program image prior to extracting the embedded first policy, loading the first application program image, and applying the extracted first policy to the first application program image; and
extracting the embedded first policy, loading the first application program image, and applying the extracted first policy to the first application program image subsequent to verifying the integrity of the first application program image.
5. The method of claim 1, further comprising storing the extracted first policy in a policy repository.
storing the extracted first policy in a policy table on the computing system.
verifying the integrity of the first application program image prior to extracting the first policy.
embedding the first policy within the first application program image.
compiling the first policy from a non-executable version in a programming language into an executable version.
10. A method in a computing system having a memory and a processor for receiving an embedded policy, the method comprising:
tracking the execution of a second instance of the second application program;
so that the second instance of the second application program is restricted from accessing computer resources in accordance with the access restrictions defined by the second policy that is embedded within the second application program; and
applying the third policy applicable to the first application program that is stored in the policy repository
so that the first application program is restricted from accessing computer resources in accordance with the access restrictions defined by the third policy applicable to the first application program that is stored in the policy repository, and
verifying the integrity of the first application program image prior to extracting the first policy from the first application program image.
15. The method of claim 14, further comprising storing the extracted first policy in a policy repository.
16. The method of claim 15, wherein the first policy is declared using XML.
18. A system having a memory and a processor for applying an embedded policy, the system comprising:
a component that receives a request to load an image of a first application program, the image of the first application program containing the first application program;
a component that determines whether a first policy is embedded within the first application program, the first policy defining access restrictions for the first application program, such that the first application program contains the embedded first policy, wherein the first policy is coded in a programming language;
a component that, responsive to determining that a first policy is embedded within the first application program:
extracts the first policy from the first application program,
loads the image of the first application program on the computer for execution by the processor,
starts execution of the first application program,
intercepts a call by the first application program to access a resource, and
executes, with a processor, the code of the extracted first policy to determine whether to allow or deny the access,
upon determining that the access is allowed, enables the access, and
upon determining that the access is not allowed, prevents the access
so that the first application program is restricted from accessing computer resources in accordance with the access restrictions defined by the first policy embedded within the first application program;
a component that embeds a second policy within a second application program, wherein the second policy defines access restrictions for the second application program, so that the second application program contains the embedded second policy;
a component that accesses a directed graph that represents system calls normally issued by the second application program, wherein the directed graph was previously generated by tracking previous instances of the second application program;
a component that tracks the execution of a second instance of the second application program; and
a component that upon detecting, based on the tracking and the directed graph, an anomalous condition in the execution of the second instance of the application program,
extracts the embedded second policy from within the second application program, and
applies the extracted second policy to the second instance of the application program
a component that, responsive to determining that a first policy is not embedded in the first application program:
loads the first application for execution on the computer, and
applies the third policy applicable to the first application program that is stored in the policy repository
when a third policy applicable to the first application program is not stored in the policy repository, does not load the first application program for execution on the computer.
a component that extracts the embedded first policy and loads the image of the first application program subsequent to verifying the integrity of the image of the first application program.
a component that stores the extracted first policy in a policy repository.
22. The system of claim 18, wherein the embedded first policy is declared using XML.
a component that compiles the first policy from a non-executable version in a programming language into an executable version.
24. The system of claim 18, wherein the extracted first policy is stored in a policy table on the computer.
a component that verifies the integrity of the image of the first application program prior to extracting the embedded first policy, loading the image of the first application program, and applying the extracted first policy to the image of the first application program executing on the computer.
a component that embeds the first policy within the image of the first application program.
27. The system of claim 18 wherein the first policy is compiled from a non-executable version in a programming language into an executable version.
28. A system having a memory and a processor for applying an embedded policy, the system comprising:
loads the image of the first application program on the computer for execution by the processor;
intercepts a call by the first application program to access a resource, and upon intercepting the call,
a component that tracks the execution of a second instance of the second application program;
a component that verifies the integrity of the first application program image prior to the extraction of the first policy from the first application program image.
FIG. 11 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a policy on a target process.
FIG. 12 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a revocable policy on a target process.
FIG. 13 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a self-imposed policy on a process.
FIG. 14 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a revocable self-imposed policy on a process.
FIG. 15 is a block diagram illustrating a communications flow used by the facility in some embodiments to perform a client-server access control check.
FIG. 16 illustrates a process by which the facility extracts a policy embedded in an application program, according to some embodiments.
FIG. 17 is a flow chart of a method by which the facility loads and applies a policy on a legacy application program, according to some embodiments.
DETAILED DESCRIPTION A software facility (�facility�) for protecting a computer system from the adverse effects arising from exploits against application and operating system programs on the computer system is described. In some embodiments, the facility adds a logic-driven access control layer to the operating system. The facility may provide an authorization module that receives authorization queries for various security-sensitive resource accesses and returns a decision to allow or deny a resource access based on a policy. A policy is a set of rules and practices that determine how a resource�such as, by way of example, a network, a file system, an application program, etc.�is managed and protected.
The authorization module may be queried directly by the various operating system components that service resource access requests issued by user mode programs, e.g., application programs executing in a user context. Alternatively, the authorization module may be queried by an �interception layer� sitting on top of such operating system components. The interception layer is code that intercepts the system call functions used by the user mode programs to access the resources, and applies �wrappers� to the intercepted system call functions. The authorization module makes its access control decisions (i.e., allow or deny) based on an identity of a principal, which is either the identity of the application program�e.g., application process�attempting the resource access, the identity of a user, or a combination of the identity of the application program and the identity of the user on whose behalf the application program is executing; a policy that applies to the principal; and the identity of the resource and action that the principal seeks to perform.
In some embodiments, the facility enables a policy, e.g., access restrictions, to be a part of the software comprising the application program. Here, it is expected that the operating system, or other comparable program or process, would or will recognize the presence of the policy embedded in the application program, extract the policy, and apply the policy. This may be accomplished, for example, by placing a special flag in the code to inform the operating system of the presence of the embedded policy, by a key set in the registry by the application's installer, by a new field in the portable executable header field of the application program, and by other methods of delimiting the embedded policy within the application code and signifying the presence of the embedded policy within the application code. The embedded policy is extracted from the software and enforced before the code comprising the application starts executing.
The embedded policy may be in the form of explicit rules or access restrictions declared in a human-readable format, such as XML. Alternatively, the embedded policy may be coded, e.g., using a programming language, and executed by an operating system access control service. By way of example, a policy may be embedded in the code and delivered with the application program when (1) dynamic policies are not required and the application program will not at any point request the facility to invoke a new policy, or (2) to retrofit a legacy application program. Thus, if the code has defects exploited by malicious code, the attack damage can be greatly reduced and contained.
In some embodiments, the application program code may be signed to protect both the application program code and the embedded policy. The application loader, e.g., longhorn loader, checks the integrity of the signed images before the code is loaded, and loads the application program images only if the signature matches the contents.
In some embodiments, a policy for an application program may be delivered by a program other than the application program to which the policy applies. For example, a policy for an application program may be delivered by an installer program for the application program. The installer program can deliver the policy for the application program to a central policy repository, where the policy is associated with the application program. The policy in the repository may then be applied before the corresponding application program is loaded and/or executed. In this manner, a policy for an existing or legacy application program can be delivered and applied without altering the legacy application program.
The various embodiments of the facility and its advantages are best understood by referring to FIGS. 1-17 of the drawings. The elements of the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the invention. Throughout the drawings, like numerals are used for like and corresponding parts of the various drawings.
In some embodiments, the facility may include an optional anomaly detection module 214 as depicted by the broken or �dashed� lines in FIG. 2. Anomaly detection module 214 generally functions to monitor the behavior of computer system 100 and the programs executing on computer system 100 in order to detect an anomalous state. In some embodiments, anomaly detection module 214 provides the facility a first notification upon detecting an anomaly and a subsequent, second notification upon detecting the cessation of the previously detected anomaly. This enables the facility to activate the enforcement of policies 206 upon detection of an anomaly, until the anomaly has ended and policies 206 are no longer enforced. Alternatively, the facility may initially impose a less restrictive set of policies until an anomaly is detected, in which case a more restrictive set of policies are enforced, until the anomaly has ended and the less restrictive set of policies are again enforced. Anomaly detection module 214 may detect an anomaly in either a single process executing on computer system 100, a group of processes executing on computer system 100, or the entire computer system 100.
FIG. 5 illustrates a flow chart of a method 500 by which the facility performs auditing of inherently dangerous operations, according to some embodiments. By way of example, a user (e.g., UserABC) may have logged on to a computer and started a web browser program (e.g., WebBrowser) and requested to access a web page (e.g., PageX) on an untrusted web site (e.g., WebSiteY). As a result, WebBrowser issues a request to retrieve PageX from WebSiteY. Steps 502-508 are substantially similar to steps 402408 of method 400.
FIG. 11 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a policy on a target process. By way of example, a network server process executing on a computer may want to set a policy for a listener process that is configured to listen for and receive network packets on behalf of the server process. In this instance, the server process may be considered a controlling process, and the listener process may be considered a target or controlled process.
As illustrated in FIG. 11, a controlling process 1102 sends a request to set a policy on a controlled process 1108 to operating system 1104 running on the computer (Stage 1). The policy may be sent with the request or may have been previously sent, in which case the request may include an identifier that identifies the policy. The request is made through an access control API 1106. Access control API 1106 generally functions to expose and make available various interfaces that may be used by application developers to set and revoke policies. In one embodiment, access control API 1106 provides the calling conventions by which an application program accesses operating system 1104 to set and revoke policies.
In response to receiving the request to set a policy, operating system 1104 checks to determine whether controlling process 1102 possesses adequate privilege to set a policy on a target process (Stage 2). For example, operating system 1104 may require controlling process 1102 to be executing at a higher privilege level than the privilege level controlled process 1108 will be executing at. Alternatively, operating system 1104 may only allow a process to set a policy on a child process. If operating system 1104 determines that controlling process 1102 has adequate privilege, then operating system 1104 sets the policy on controlled process 1108. If the request includes the policy, operating system 1104 stores the received policy in, for example, policies 206, and sets an indication to apply the policy. If the request includes an identifier identifying the policy, operating system 1104 uses the identifier to identify, e.g., locate, the policy in, for example, policies 206, and sets an indication to apply the policy. Otherwise, if operating system 1104 determines that controlling process 1102 does not have adequate privilege, then operating system 1104 does not set the policy on controlled process 1108. Operating system 1104 returns to controlling process 1102 the results of the request to set a policy on controlled process 1108 (Stage 3).
Subsequently, when controlled process 1108 makes a request to access a resource to operating system 1104 (Stage 4), operating system 1104 performs an access control check to determine whether controlled process 1108 has authorization to access the resource (Stage 5). For example, operating system 1104 may utilize authorization module 202 to determine whether there is an applicable policy and apply the rules in the applicable policy to determine whether controlled process 1108 has authorization to access the resource.
Depending on the results of the access control check, operating system 1104 services the request to access the resource. For example, if operating system 1104 determines by applying the applicable policy that controlled process 1108 has authorization to access the resource, operating system 1104 proceeds to further process the request to access the resource. Otherwise, operating system 1104 does not further process the request to access the resource. Operating system 1104 returns to controlled process 1108 the results of the request to access the resource (Stage 6).
Even though controlling process 1102 and operating system 1104 are depicted as running on the same computer in the above and subsequent examples, it is not meant to be limiting as those of skill in the art will appreciate that controlling process 1102 need not be running on the same computer as operating system 1104. For example, the request to set the policy may be sent over a communications network. Additionally, it will also be appreciated that controlled process 1108 may or may not be in existence at the time of the request to set a policy on controlled process 1108.
FIG. 12 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a revocable policy on a target process. A controlling process 1202 sends, via access control API 1106, a request to set a revocable policy on a controlled process 1204 to operating system 1104 running on a computer (Stage 1). In response to receiving the request to set a revocable policy, operating system 1104 checks to determine whether controlling process 1202 possesses adequate privilege to set a revocable policy on a target process (Stage 2). If operating system 1104 determines that controlling process 1202 has adequate privilege, then operating system 1104 sets an indication to apply the policy on controlled process 1204. Otherwise, if operating system 1104 determines that controlling process 1202 does not have adequate privilege, then operating system 1104 does not set the policy on controlled process 1204.
Operating system 1104 returns to controlling process 1202 the results of the request to set a revocable policy on controlled process 1204 (Stage 3). If the revocable policy was successfully set, operating system 1104 returns an identifier in, for example, a �cookie� to controlling process 1202. In one embodiment, the identifier authenticates the process that set the revocable policy, and is used to identify and revoke the revocable policy. Stated another way, the identifier is akin to a privilege or authorization to revoke the revocable policy, and is subsequently submitted to operating system 1104 with a request to revoke the policy. In other embodiments, the cookie may also include state information, such as an identifier that identifies a policy that was previously in effect.
Subsequently, when controlled process 1204 makes a request to access a resource to operating system 1104 (Stage 4), operating system 1104 performs an access control check to determine whether controlled process 1204 has authorization to access the resource (Stage 5). Depending on the results of the access control check, operating system 1104 services the request to access the resource. For example, if operating system 1104 determines by applying the applicable policy that controlled process 1204 has authorization to access the resource, operating system 1104 proceeds to further process the request to access the resource. Otherwise, operating system 1104 does not further process the request to access the resource. Operating system 1104 returns to controlled process 1204 the results of the request to access the resource (Stage 6).
Controlling process 1202 may then send, via access control API 1106, a request to revoke a revocable policy previously set on controlled process 1204 to operating system 1104 (Stage 7). Alternatively, controlling process 1202 may send the cookie containing the identifier to controlled process 1204 (Stage 8), and controlled process 1204 may subsequently send, via access control API 1106, a request to revoke a revocable policy previously set on controlled process 1204 to operating system 1104 (Stage 9). In both instances, the cookie is sent with the request to revoke a revocable policy.
In response to receiving the request to revoke a revocable policy, operating system 1104 uses the identifier contained in the cookie to authenticate the requester as a process having authorization to revoke the indicated revocable policy. Operating system 1104 may also use the identifier to identify the policy that is to be revoked. Subsequent to authenticating the requestor�either controlling process 1202 (Stage 7) or controlled process 1204 (Stage 9),�operating system 1104 revokes the revocable policy currently being applied to controlled process 1202. In another embodiment, operating system 1104 may apply a policy that was being applied to controlled process 1204 prior to the application of the just revoked revocable policy. For example, an identifier that identifies the policy that was previously in effect may be passed to operating system 1104 in the cookie that was sent with the request to revoke a revocable policy. Alternatively, operating system 1104 may have preserved the state information prior to applying the revocable policy, for example, in a persistent storage device on the computer.
FIG. 13 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a self-imposed policy on a process. By way of example, a user on a computer may have just activated a web browser application program. As part of the initialization process, a web browser application process 1302 sends, via access control API 1106, a request to set my policy to PolicyA to operating system 1104 running on the computer (Stage 1). In response, operating system 1104 sets the policy for process 1302 to PolicyA (Stage 2). If the request includes PolicyA, operating system 1104 stores PolicyA in, for example, policies 206, and sets an indication to apply PolicyA. If the request includes an identifier identifying PolicyA, operating system 1104 uses the identifier to identify, e.g., locate, PolicyA in, for example, policies 206, and sets an indication to apply PolicyA. Operating system 1104 returns to process 1302 the results of the request to set my policy to PolicyA (Stage 3).
Subsequently, process 1302 continues processing with PolicyA being active (Stage 4). The processing may involve interaction with operating system 1104. For example, the user may use process 1302 to upload one or more web applications. Having uploaded a web application, the user may have requested processing of the uploaded web application through process 1302. In response to the user's request, process 1302 sends, via access control API 1106, a request to set my policy to PolicyB to operating system 1104 (Stage 5). For example, process 1302, not trusting the integrity of the uploaded and user initiated web application, requests to set the policy to a more stringent PolicyB. In response, operating system 1104 sets the policy for process 1302 to PolicyB (Stage 6). Operating system 1104 returns to process 1302 the results of the request to set my policy to PolicyB (Stage 7).
Depending on the returned results of the request to set the policy to PolicyB, process 1302 continues processing (Stage 8). For example, if the request to set the policy to PolicyB was successful, process 1302 starts execution of the requested web application. Here, the more stringent PolicyB is applied to the web application process. Alternatively, if the request to set the policy to PolicyB was unsuccessful, process 1302 does not start execution of the web application and may inform the user of an error condition, e.g., reason for not running the web application.
In some embodiments, PolicyB is applied to the web application process and PolicyA is in effect revoked. In this instance, PolicyA may have been a revocable policy. In some embodiments, both PolicyA and PolicyB are applied to the web application process. Here, PolicyA may have been irrevocable and, thus, remains in effect along with PolicyB.
FIG. 14 is a block diagram illustrating a communications flow used by the facility in some embodiments to set a revocable self-imposed policy on a process. By way of example, a user on a computer may be running an application program, and may have come to a point where a macro is to be executed. Knowing the processing that is to be performed by the macro, application process 1402 sends, via access control API 1106, a request to set my revocable policy to PolicyA to operating system 1104 running on the computer (Stage 1). For example, PolicyA may be a more restrictive policy than a policy that is currently being applied to process 1402.
In response, operating system 1104 sets the policy for process 1402 to PolicyA (Stage 2), and returns to process 1402 the results of the request to set my revocable policy to PolicyA (Stage 3). If PolicyA was successfully set, operating system 1104 may also return a cookie containing an identifier and/or state information, e.g., information regarding any previous policy that was being applied prior to PolicyA, to process 1402. The identifier is used to authenticate the holder as a process that has authorization to revoke the revocable policy.
Depending on the returned results of the request to set the revocable policy to PolicyA, process 1402 continues processing (Stage 4). For example, if the request to set the revocable policy to PolicyA was successful, process 1402 proceeds with executing the macro. Here, the more restrictive PolicyA is applied to the macro. Alternatively, if the request to set the revocable policy to PolicyA was unsuccessful, process 1402 may not proceed with executing the macro.
Subsequently, for example, after detecting that the macro has finished executing, process 1402 sends, via access control API 1106, a request to revoke my policy, e.g., PolicyA, to operating system 1104 (Stage 5). Process 1402 submits the �cookie� that was previously received from operating system 1104 with the request to revoke my policy. In response to receiving the request to revoke my policy, operating system 1104 uses the identifier contained in the cookie to authenticate process 1402 as a process having authorization to revoke the policy. Subsequent to authenticating process 1402, operating system 1104 revokes PolicyA, and applies the policy identified in the cookie to process 1402 (Stage 6). Operating system 1104 returns to process 1402 the results of the request to revoke my policy (Stage 7), and process 1402 continues processing (Stage 8). In another embodiment, the revoke my policy request may identify a policy that is to be applied subsequent to revoking the current revocable policy.
FIG. 15 is a block diagram illustrating a communications flow used by the facility in some embodiments to perform a client-server access control check. By way of example, an email client process 1502 may call an email server process 1504 to send an email message to an addressed recipient (Stage 1). Client process 1502 sends its identifier, e.g., a ClientID, as part of the call to server process 1504. In response, before attempting to send the email message to the addressed recipient, server process 1504 performs a check to determine whether client process 1504 has sufficient privileges to perform the requested action, e.g., in this case, send the email to the addressed recipient. Thus, server process 1504 impersonates client process 1502 by assuming the identity of client process 1502 (Stage 2).
Having assumed the identity of client process 1502, server process 1504, sends, via access control API 1106, a request to perform an access control check to operating system 1104 (Stage 3). The request includes the identity of client process 1502, e.g., ClientID, and the requested action, e.g., send an email message to the addresses recipient. Operating system 1104 performs the access control check and sends server process 1504 an indication of whether client process 1502 has authorization to perform the requested action. In some embodiments, operating system 1104 may check an applicable policy in policies 206 to determine whether client process 1502 has authorization to perform the requested action. In some embodiments, operating system 1104 may utilize authorization module 202 to determine whether client process 1502 has authorization to perform the requested action. Depending on the results of the access control check, server process 1504 either continues processing the email message, e.g., sends the emails message to the addressed recipient, or stops processing the email message and sends client process 1502 an error message. While server process 1504 sent the request to perform the access control check to operating system 1104 in the above example, it will be appreciated that server process 1504 may have directly invoked authorization module 202 to perform the access control check.
FIG. 16 illustrates a process by which a policy embedded in an application program is extracted, according to some embodiments. This allows the policy to be delivered as a part of the software package comprising the application, and the policy is extracted and applied before any of the code comprising the application starts executing. Thus, using this approach, if the code contains defects exploited by malicious code, the attack damage can be reduced and/or contained.
At step 1602, a policy is embedded as part of the code of an application program. The embedded policy is delimited in the application code. In some embodiments, the policy within the code is delimited, for example, by placing in the executable code a flag, which indicates to an operating system or other process suitable for extracting the embedded policy of the presence of the policy. At step 1604, the application program code is signed to protect the resulting image. Code signing provides an assurance that the signed image comes from the provider of the digital signature, e.g., the signer of the code. Digital signatures using a public key and a private key are generally known to those of ordinary skill in the art and, thus, will not be further discussed herein.
Subsequently, at step 1606, a request is made to load the application program image, for example, on a computer. At step 1608, the operating system, or a loader component of the operating system, checks the integrity of the application program image. If the operating system determines the integrity of the application program image is not acceptable (step 1610), then at step 1618, the operating system does not load the application program image on the computer. The operating system may also generate an error condition and provide an indication of the error.
Alternatively, if the operating system determines the integrity of the application program image is acceptable (step 1610), then at step 1612, the operating system loads the application program image on the computer. At step 1614, the operating system checks for the presence of an embedded policy, and if an embedded policy is detected, extracts the policy from the application program image. In some embodiments, the operating system may store the extracted policy in a policy table or repository, e.g., policies 206, provided by the operating system. At step 1616, the operating system applies the extracted policy to the loaded application program image.
FIG. 17 is a flow chart of a method 1700 by which the facility loads and applies a policy on a legacy application program, according to some embodiments. By way of example, a legacy application program may be stored on a computer. Wanting to apply a policy to the legacy application program without incurring the risks associated with modifying the legacy application code or the hassles and costs associated with uninstalling, reinstalling and reconfiguring a potentially large number of legacy application programs, a policy for the legacy application program may be delivered by a process independent of the legacy application program.
Beginning at a start step, an operating system executing on a computer hosting legacy application program receives a request from a process to load a policy for the legacy application program at step 1702. For example, the process may be an instance of an update program executing on the computer. Moreover, in addition to the rules that may be included in a policy, the policy may further include rules which are dependent and applicable based on information such as, the version of the legacy application code, the patch level incorporated in the legacy application code, and the like. At step 1704, the operating system receives the policy from the process and loads the policy for the legacy application program. The operating system may validate the process as being authorized to deliver a policy applicable to the legacy application program. The operating system may also validate the integrity of both the process and the policy prior to receiving and storing the policy. In some embodiments, the operating system loads the policy in a policy table or repository and associates the policy to the legacy application program. The association may be indicated by metadata of the policy.
Subsequently, at step 1706, the operating system receives a request to load the legacy application program. At step 1708, the operating system checks to determine if there is a policy that is applicable to the legacy application program. If the legacy application program does not have an applicable policy, then at step 1704, the operating system does not load the legacy application program. In this instance, the operating system may be configured to only load and execute applications that have applicable policies in effect. The operating system may return an error that indicates the failure to load the legacy application program. Subsequent to providing the indication of the error, the operating system continues processing.
If, at step 1708, the operating system determines that the legacy application program does have an applicable policy, then at step 1710, the operating system loads the legacy application program. At step 1712, the operating system applies the policy to the legacy application program during its execution, and continues processing.
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except in accordance with elements explicitly recited in the appended claims.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4584639Dec 23, 1983Apr 22, 1986Key Logic, Inc.Computer security systemUS5187790Apr 21, 1992Feb 16, 1993Digital Equipment CorporationServer impersonation of client processes in an object based computer operating systemUS5974549Mar 27, 1997Oct 26, 1999Soliton Ltd.Security monitorUS6317742Jan 9, 1997Nov 13, 2001Sun Microsystems, Inc.Method and apparatus for controlling software access to system resourcesUS6353886Nov 24, 1998Mar 5, 2002Alcatel Canada Inc.Method and system for secure network policy implementationUS6412070Sep 21, 1998Jun 25, 2002Microsoft CorporationExtensible security system and method for controlling access to objects in a computing environmentUS6480692Mar 13, 2001Nov 12, 2002Bridgestone CorporationToner supply roller and developing apparatusUS6625603Sep 21, 1998Sep 23, 2003Microsoft CorporationObject type specific access controlUS6647388Dec 15, 2000Nov 11, 2003International Business Machines CorporationAccess control system, access control method, storage medium and program transmission apparatusUS6681331May 11, 1999Jan 20, 2004Cylant, Inc.Dynamic software system intrusion detectionUS6691232Aug 5, 1999Feb 10, 2004Sun Microsystems, Inc.Security architecture with environment sensitive credential sufficiency evaluationUS6762764Apr 19, 2002Jul 13, 2004Kabushiki Kaisha ToshibaSystem and method for processing image, and compiler for use in this systemUS6957261Jul 17, 2001Oct 18, 2005Intel CorporationResource policy management using a centralized policy data structureUS7013332Jan 9, 2001Mar 14, 2006Microsoft CorporationDistributed policy model for access controlUS7020645Apr 19, 2001Mar 28, 2006Eoriginal, Inc.Systems and methods for state-less authenticationUS7080077Feb 26, 2001Jul 18, 2006Oracle International CorporationLocalized accessUS7103914Jun 17, 2003Sep 5, 2006Bae Systems Information Technology LlcTrusted computer systemUS7185192Jul 7, 2000Feb 27, 2007Emc CorporationMethods and apparatus for controlling access to a resourceUS7231661Jun 21, 2001Jun 12, 2007Oracle International CorporationAuthorization services with external authenticationUS7251831Apr 19, 2001Jul 31, 2007International Business Machines CorporationMethod and system for architecting a secure solutionUS7506364Oct 1, 2004Mar 17, 2009Microsoft CorporationIntegrated access authorizationUS7685632Oct 1, 2004Mar 23, 2010Microsoft CorporationAccess authorization having a centralized policyUS7818781Oct 1, 2004Oct 19, 2010Microsoft CorporationBehavior blocking access controlUS7853993Jan 5, 2009Dec 14, 2010Microsoft CorporationIntegrated access authorizationUS7904956Oct 1, 2004Mar 8, 2011Microsoft CorporationAccess authorization with anomaly detectionUS20020091798Feb 26, 2001Jul 11, 2002Joshi Vrinda S.Providing data to applications from an access systemUS20020099952Jun 8, 2001Jul 25, 2002Lambert John J.Policies for secure software executionUS20020157015Apr 19, 2001Oct 24, 2002International Business Machines CorporationMethod and system for architecting a secure solutionUS20020188568Jan 8, 2002Dec 12, 2002Center 7, Inc.Systems and methods of containing and accessing generic policyUS20020199109Jun 25, 2001Dec 26, 2002Boom Douglas D.System, method and computer program for the detection and restriction of the network activity of denial of service attack softwareUS20030009675 *Jul 2, 2002Jan 9, 2003Rygaard Christopher A.Mobile application access control list security systemUS20030023873Mar 16, 2001Jan 30, 2003Yuval Ben-ItzhakApplication-layer security method and systemUS20030115179Nov 1, 2002Jun 19, 2003Senthil PrabakaranConfiguration management for group policiesUS20030159070Nov 22, 2002Aug 21, 2003Yaron MayerSystem and method for comprehensive general generic protection for computers against malicious programs that may steal information and/or cause damagesUS20040010519Dec 20, 2002Jan 15, 2004Sinn Richard P.Rule based data managementUS20040128537Dec 30, 2002Jul 1, 2004International Business Machines CorporationRetrospective policy safety netUS20040139202Jan 10, 2003Jul 15, 2004Vanish TalwarGrid computing control systemUS20040181788Mar 14, 2003Sep 16, 2004Websense IncSystem and method of monitoring and controlling application filesUS20050097353Oct 8, 2004May 5, 2005Bea Systems, Inc.Policy analysis toolUS20050177724Jan 14, 2005Aug 11, 2005Valiuddin AliAuthentication system and methodUS20050256664Jun 30, 2004Nov 17, 2005Microsoft CorporationEfficient patchingUS20050257207Jun 30, 2004Nov 17, 2005Microsoft CorporationEfficient patchingUS20050257208Jun 30, 2004Nov 17, 2005Microsoft CorporationEfficient patchingUS20060005227Jul 1, 2004Jan 5, 2006Microsoft CorporationLanguages for expressing security policiesUS20060075461Oct 1, 2004Apr 6, 2006Microsoft CorporationAccess authorization having a centralized policyUS20060075462Oct 1, 2004Apr 6, 2006Microsoft CorporationAccess authorization having embedded policiesUS20060075464Oct 1, 2004Apr 6, 2006Microsoft CorporationAccess authorization APIUS20060075469Oct 1, 2004Apr 6, 2006Microsoft CorporationIntegrated access authorizationUS20060075492Oct 1, 2004Apr 6, 2006Microsoft CorporationAccess authorization with anomaly detectionUS20070143851Jun 13, 2006Jun 21, 2007FiberlinkMethod and systems for controlling access to computing resources based on known security vulnerabilitiesUS20090150990Jan 5, 2009Jun 11, 2009Microsoft CorporationIntegrated access authorizationEP1320010A2Dec 11, 2002Jun 18, 2003Pervasive Security Systems Inc.Secured data format for access controlJP2003233521A Title not availableJP2004192601A Title not availableKR19980070410A Title not availableKR20030096277A Title not availableKR20040019033A Title not availableWO2000056027A1Mar 15, 2000Sep 21, 2000Texar Software CorpComputer security system* Cited by examinerNon-Patent CitationsReference1"Audit-Failed Logon Attempts by Undefined User Accounts," IBM Technical Disclosure Bulletin, IBM Corporation, vol. 37, No. 6A, Jun. 1, 1994.2Advisory Action mailed Oct. 20, 2008, U.S. Appl. No. 10/957,029.3Ashley, P. et al., "Applying Authorization to Intranets: Architectures, Issues and APIs," Computer Communications, Elsevier Science Publishers BV, Amsterdam, NL, vol. 23, No. 17, Nov. 1, 2000.4Ashley, P., et a., "Applying Authorization to Intranets: Architectures, Issues and APIs," Computer Communications, vol. 23, No. 17, Nov. 1, 2000 (pp. 1613-1620).5Australian Communication dated May 18, 2010, in AU Application No. 2005209678.6Australian Notice of Acceptance dated May 23, 2011, in AU Application No. 2005209678.7China Patent Office of the People's Republic of China Notice on First Office Action mailed Apr. 10, 2009, in China Application No. 200510108862.7, 8 pages.8Chinese Notice on First Office Action dated Dec. 12, 2008, in Chinese Application No. 200510108867.X.9Chinese Notice on Grant of Patent Right For Invention dated Jan. 15, 2010, in Chinese Application No. 200510108867.X.10Chinese Second Office Action dated Jun. 26, 2009, in Chinese Application No. 200510108867.X.11European Communication from the Examination Division dated Aug. 6, 2008, in EP Application No. 05108532.2.12European Communication from the Examination Division dated Nov. 19, 2009, in EP Application No. 05108532.2.13European Communication from the Examination Division dated Sep. 10, 2007, in EP Application No. 05108532.2.14European Communication mailed Mar. 10, 2010, in Application No. 05108704.7, 6 pages.15European Communication mailed May 22, 2007, in Application No. 05108704.7, 10 pages.16European Search Report for EP Patent Application No. 05108704.7, Microsoft Corporation, Mar. 3, 2006.17European Search Report, European Patent Application No. 05 10 8704, Microsoft Corporation, Sep. 15, 2006.18Final Office Action mailed Jun. 23, 2008, U.S. Appl. No. 10/957,029.19Final Office Action mailed Jun. 26, 2008, U.S. Appl. No. 10/956,215.20Final Office Action mailed May 12, 2008, U.S. Appl. No. 10/957,314.21Final Office Action mailed May 14, 2008, U.S. Appl. No. 10/957,509.22Final Office Action mailed May 27, 2009, U.S. Appl. No. 10/957,314.23Final Office Action mailed Sep. 15, 2009, U.S. Appl. No. 10/957,029.24Godik S., et al., OASIS, Extensible Access Control Markup Language (XACML), Version 1.0, OASIS Standard, Feb. 18, 2003.25International Telecommunication Union, ITU-T Recommendation X.812, Data Networks and Open System Communications Security, Nov. 1995 (pp. 1-30).26International Telecommunication Union, ITU-T, Data Networks and Open System Communications Security, Information Technology-Open Systems Interconnection-Security Frameworks for Open Systems: Access Control Framework, Nov. 1995.27International Telecommunication Union, ITU-T, Data Networks and Open System Communications Security, Information Technology�Open Systems Interconnection�Security Frameworks for Open Systems: Access Control Framework, Nov. 1995.28Japanese Final Rejection mailed on Oct. 21, 2011, in Japanese Patent Application No. 2005-290091, 5 pages.29Japanese Notice of Rejection in Application 2011-220994, mailed Jan. 13, 2012, 6 pgs.30Japanese Notice of Rejection in Application 2011220995, mailed Dec. 22, 2011, 9 pgs.31Japanese Notice of Rejection in Application 2011220996, mailed Dec. 22, 2011, 9 pgs.32Japanese Notice of Rejection mailed on Jul. 5, 2011, in Japanese Patent Application No. 2005-290091, 4 pages.33Japanese Response filed on Oct. 5, 2011, in Japanese Patent Application No. 2005290091, 7 pages.34Korean Response filed Aug. 2, 2011, filed in Korean Application No. 10-2005-79907, 41 pages.35Microsoft Press Computer Dictionary: The Comprehensive Standard for Business, School, Library, and Home (2d ed., 1994), pp. 43-44.36Non-Final Office Action mailed Apr. 1, 2010, U.S. Appl. No. 10/957,314.37Non-Final Office Action mailed Feb. 5, 2010, U.S. Appl. No. 10/957,029.38Non-Final Office Action mailed Mar. 5, 2009, U.S. Appl. No. 10/957,029.39Non-Final Office Action mailed May 12, 2010 in U.S. Appl. No. 12/348,649.40Non-Final Office Action mailed May 27, 2009, U.S. Appl. No. 10/956,215.41Non-Final Office Action mailed Nov. 13, 2009, U.S. Appl. No. 10/957,314.42Non-Final Office Action mailed Nov. 14, 2007, U.S. Appl. No. 10/957,029.43Non-Final Office Action mailed Nov. 2, 2007, U.S. Appl. No. 10/957,509.44Non-Final Office Action mailed Oct. 17, 2007, U.S. Appl. No. 10/957,314.45Non-Final Office Action mailed Oct. 26, 2007, U.S. Appl. No. 10/956,215.46Non-Final Office Action mailed Oct. 27, 2008, U.S. Appl. No. 10/957,314.47Non-Final Office Action mailed Oct. 29, 2009 in U.S. Appl. No. 12/348,649.48Non-Final Office Action mailed Oct. 31, 2008, U.S. Appl. No. 10/956,215.49Non-Final Office Action mailed Sep. 7, 2011, U.S. Appl. No. 12/944,667, 5 pages.50Notice of Allowance mailed Aug. 23, 2010, in U.S. Appl. No. 10/957,029.51Notice of Allowance mailed Aug. 4, 2010, in U.S. Appl. No. 10/957,314.52Notice of Allowance mailed Jan. 5, 2010, in U.S. Appl. No. 10/957,029.53Notice of Allowance mailed Oct. 3, 2008, in U.S. Appl. No. 10/957,509.54Notice of Allowance mailed Sep. 20, 2010, in U.S. Appl. No. 12/348,649.55Partial European Search Report for EP Application No. 05108532.2, dated Aug. 16, 2006.56Reply to Chinese Notice on First Office Action dated Dec. 12, 2008, in Chinese Application No. 200510108867.X, filed Apr. 22, 2009.57Reply to Chinese Second Office Action dated Jun. 26, 2009, in Chinese Application No. 200510108867.X, filed Aug. 14, 2009.58Reply to European Communication from the Examination Division dated Aug. 6, 2008, in EP Application No. 05108532.2, filed Dec. 9, 2008.59Reply to European Communication from the Examination Division dated Nov. 19, 2009, in EP Application No. 05108532.2, filed Mar. 19, 2010.60Reply to European Communication from the Examination Division dated Sep. 10, 2007, in EP Application No. 05108532.2, filed Jan. 17, 2008.61Response Non-Final Office Action mailed Oct. 17, 2007, U.S. Appl. No. 10/957,314, filed Jan. 17, 2008.62Response to Australian Communication dated May 18, 2010, in AU Application No. 2005209678, filed May 13, 2011.63Response to European Communication mailed May 22, 2007, in Application No. 05108704.7, dated Oct. 8, 2007, 15 pages.64Response to Final Office Action mailed Jun. 23, 2008, U.S. Appl. No. 10/957,029, filed Sep. 23, 2008.65Response to Final Office Action mailed Jun. 26, 2008, U.S. Appl. No. 10/956,215, filed Sep. 26, 2008.66Response to Final Office Action mailed May 12, 2008, U.S. Appl. No. 10/957,314, filed Aug. 12, 2008.67Response to Final Office Action mailed May 14, 2008, U.S. Appl. No. 10/957,509, filed Aug. 14, 2008.68Response to Final Office Action mailed May 27, 2009, U.S. Appl. No. 10/957,314, filed Aug. 27, 2009.69Response to Final Office Action mailed Sep. 15, 2009, U.S. Appl. No. 10/957,029, filed Dec. 15, 2009.70Response to Non-Final Office Action mailed Apr. 1, 2010, U.S. Appl. No. 10/957,314, filed May 27, 2010.71Response to Non-Final Office Action mailed Feb. 5, 2010, U.S. Appl. No. 10/957,029, filed May 5, 2010.72Response to Non-Final Office Action mailed Mar. 5, 2009, U.S. Appl. No. 10/957,029, filed Jun. 5, 2009.73Response to Non-Final Office Action mailed May 12, 2010 in U.S. Appl. No. 12/348,649, filed in Aug. 4, 2010.74Response to Non-Final Office Action mailed May 27, 2009, U.S. Appl. No. 10/956,215, filed Aug. 27, 2009.75Response to Non-Final Office Action mailed Nov. 13, 2009, U.S. Appl. No. 10/957,314, filed Jan. 19, 2010.76Response to Non-Final Office Action mailed Nov. 14, 2007, U.S. Appl. No. 10/957,029, filed Mar. 14, 2008.77Response to Non-Final Office Action mailed Nov. 2, 2007, U.S. Appl. No. 10/957,509, filed Feb. 4, 2008.78Response to Non-Final Office Action mailed Oct. 26, 2007, U.S. Appl. No. 10/956,215, filed Mar. 26, 2008.79Response to Non-Final Office Action mailed Oct. 27, 2008, U.S. Appl. No. 10/957,314, filed Feb. 25, 2009.80Response to Non-Final Office Action mailed Oct. 29, 2009 in U.S. Appl. No. 12/348,649, filed Jan. 29, 2010.81Response to Non-Final Office Action mailed Oct. 31, 2008, U.S. Appl. No. 10/956,215, filed Mar. 2, 2009.82Russian Decision on Grant of A Patent for Invention for Russian Application No. 2005130458, dated Sep. 30, 2005. [English Translation].83Ryutov, Tatyana, et al., "Integrated Access Control and Intrusion Detection for Web Servers," IEEE Transactions on Parallel and Distributed Systems, vol. 14, No. 9, Sep. 2003 (pp. 841-850).84Sandhu, Ravi S., and Samarati, Pierangela, "Access Control: Principles and Practice," IEEE Communications Magazine 32, Sep. 1994, No. 9.85Sandhu, Ravi S., and Samarati, Pierangela, "Access Control: Principles and Practice," IEEE Communications Magazine, 32(Sep. 1994) , No. 9 (pp. 40-48).86The Authoritative Dictionary of IEEE Standards and Terms (7th ed., 2000), pp. 101-102.87U.S. Appl. No. 12/348,649, dated Jan. 2009, Vayman.88U.S. Appl. No. 12/944,667, Amendment and Response filed Dec. 7, 2011, 9 pgs.89U.S. Appl. No. 12/944,667, Office Action mailed Jan. 12, 2012, 5 pgs.Classifications U.S. Classification726/1International ClassificationH04L29/06Cooperative ClassificationG06F21/62, G06F21/54, G06F21/554, G06F21/30European ClassificationG06F21/62, G06F21/54, G06F21/55BLegal EventsDateCodeEventDescriptionJan 1, 2013CCCertificate of correctionJun 15, 2005ASAssignmentOwner name: MICROSOFT CORPORATION, WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GOLAN, GILAD;VAYMAN, MARK;REEL/FRAME:016163/0251;SIGNINGDATES FROM 20040928 TO 20040930Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GOLAN, GILAD;VAYMAN, MARK;SIGNING DATES FROM 20040928 TO20040930;REEL/FRAME:016163/0251RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google