Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Protection at a particular protocol layer
Reexamination Certificate
2000-03-30
2002-05-14
Etienne, Ario (Department: 2155)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Protection at a particular protocol layer
C713S152000, C713S152000, C709S225000, C709S229000, C710S200000, C710S240000
Reexamination Certificate
active
06389540
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed to security measures in a computer system and, more particularly, to systems and methods that control access to a resource based on the source of the code and the identity of the principal on whose behalf the code is being executed.
As the use of computer systems grows, organizations are becoming increasingly reliant upon them. A malfunction in the computer system can severely hamper the operation of such organizations. Thus, organizations that use computer systems are vulnerable to users who may intentionally or unintentionally cause the computer system to malfunction.
One way to compromise the security of a computer system is to cause the computer system to execute software that performs harmful actions on the computer system. There are various types of security measures that may be used to prevent a computer system from executing harmful software. One example is to check all software executed by the computer system with a “virus” checker. However, virus checkers only search for very specific software instructions. Therefore, many software-tampering mechanisms go undetected by a virus checker.
Another very common measure used to prevent the execution of software that tampers with a computer's resources is the “trusted developers approach.” According to the trusted developers approach, system administrators limit the software that a computer system can access to only software developed by trusted software developers. Such trusted developers may include, for example, well known vendors or in-house developers.
Fundamental to the trusted developers approach is the idea that computer programs are created by developers, and that some developers can be trusted to produce software that does not compromise security. Also fundamental to the trusted developers approach is the notion that a computer system executes only programs that are stored at locations that are under control of the system administrators.
Recently developed methods of running applications involve the automatic and immediate execution of software code loaded from remote sources over a network. When the network includes remote sources that are outside the control of system administrators, the trusted developers approach does not work.
One conventional attempt to adapt the trusted developers approach to systems that can execute code from remote sources is referred to as the trusted source approach. An important concept of the trusted source approach is the notion that the location from which a program is received (i.e., the “source” of the program) identifies the developer of the program. Consequently, the source of the program may be used to determine whether the program is from a trusted developer. If the source is associated with a trusted developer, then the source is considered to be a “trusted source” and execution of the code is allowed.
One implementation of the trusted source approach is referred to as the sand box method. The sand box method allows all code to be executed, but places restrictions on remote code. Specifically, the sand box method permits all trusted code full access to a computer system's resources and all remote code limited access to the resources. Trusted code is usually stored locally on the computer system under the direct control of the owners or administrators of the computer system, who are accountable for the security of the trusted code.
One drawback of the sand box approach is that the approach is not very flexible because it restricts access by remote code to the same limited set of resources. Conflicts can then arise when remote code from several sources attempt to access the same resources. As a result, conventional systems often limit access by remote code from one source to one set of computer resources, while limiting access by remote code from another source to a different set of computer resources. For example, a system may limit access by remote code loaded over a network from a source associated with a first computer to one set of files, and similarly limit access by remote code loaded over the network from a source associated with a second computer to another set of files.
Providing security measures that allow more flexibility than the sand box method involves establishing a complex set of relationships between principals and permissions. A “principal” is an entity in the computer system to which permissions are granted. Examples of principals include users, organizations, processes, objects, and threads. A “permission” is an authorization by the computer system that allows a principal to perform a particular action or function.
The task of assigning permissions to principals is complicated by the fact that sophisticated processes may involve the interaction of code from multiple sources. For example, code from a trusted first source being executed by a principal (e.g., a thread) may cause the execution of code from a trusted second source, and then cause execution of code from an untrusted third source.
Even though the principal remains the same when the code from the trusted second source and code from the untrusted third source are executed, the access privileges appropriate for the principal when code from the trusted second source is executed likely differ from access privileges appropriate for the principal when the code from the untrusted third source is being executed. Thus, access privileges appropriate for a principal may change dynamically as the source of the code being executed by the principal changes.
Access privileges may also change dynamically as the principal on whose behalf the code is being executed changes. Sometimes one principal executes code on behalf of another principal. For example, when a principal on one computer requests access to a resource on a remote computer, the request causes a “remote” principal to be invoked on the remote computer to handle the request. Handling of the request by the remote principal may involve the execution of code from trusted and untrusted sources. In these situations, conventional systems continue to base code access privileges on the source of the code without regard to the principal on whose behalf the code is executed. By failing to consider the principal on whose behalf the code is being executed, conventional systems ignore a possible breach in security.
Based on the foregoing, it is clearly desirable to develop a security mechanism that determines the appropriate code access privileges.
SUMMARY OF THE INVENTION
Systems and methods consistent with the principles of the present invention address this need by determining access control to code based on the source of the code and the principal on whose behalf the code is being executed. By regulating code access based on either or both of these factors, the security in computer systems can be enhanced.
A system consistent with the principles of the present invention regulates access to resources requested by an operation executing on a computer. The operation invokes a plurality of methods that operate upon code during execution. The system includes a policy file, a call stack, and an execution unit. The policy file stores permissions for the resource. The permissions authorize particular types of access to the resource based on a source of the code and an executor of the code. The call stack stores representations of the methods and executors in an order of invocation by the operation. The execution unit grants access to the resource when the types of access authorized by the permissions of all of the methods and executors on the call stack encompass the access requested by the operation.
REFERENCES:
patent: 4430699 (1984-02-01), Segarra et al.
patent: 4491946 (1985-01-01), Kryskow, Jr. et al.
patent: 4558413 (1985-12-01), Schmidt et al.
patent: 4713806 (1987-12-01), Oberlander et al.
patent: 4809160 (1989-02-01), Mahon et al.
patent: 4823122 (1989-04-01), Mann et al.
patent: 4939638 (1990-07-01), Stephenson et al.
patent: 4956773 (1990-09-01), Saito et al.
patent: 5088036 (1992-02-01
Gong Li
Scheifler Robert W.
Etienne Ario
Finnegan Henderson Farabow Garrett & Dunner LLP
LandOfFree
Stack based access control using code and executor identifiers does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Stack based access control using code and executor identifiers, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Stack based access control using code and executor identifiers will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2906263