Controlling access to a resource

Details Controlling access to a resource Controlling access to a resource

1997-12-11

2001-02-20

Beausoliel, Jr., Robert W. (Department: 2785)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Protection at a particular protocol layer

C713S152000, C709S229000

Reexamination Certificate

active

06192476

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to security mechanisms in a computer system.
BACKGROUND OF THE INVENTION
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. Many methods of using software to tamper with a computer's resources would not be detected 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 know 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 not have produced software that compromises security. Also fundamental to the trusted developers approach is the notion that a computer system will only execute 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 attempt to adapt the trusted developers approach to systems that can execute code from remote sources is referred to as the trusted source approach. Key to the trusted source approach is the notion that the location from which a program is received (e.g. 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 a computer system's 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 to the sandbox approach is that the approach is not very granular. The sandbox approach is not very granular because all remote code is restricted to the same limited set of resources. Very often, there is a need to permit remote code from one source access to one set of computer resources while permitting remote code from another source access to another set of computer resources. For example, there may be a need to limit access to one set of files associated with one bank to remote code loaded over a network from a source associated with that one bank, and limit access to another set of files associated with another bank to remote code loaded over a network from a source associated with the other bank.
Providing security measures that allow more granularity 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 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 (c.g. 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 is being executed, the access privileges appropriate for the principal when code from the trusted second source is being 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.
Based on the foregoing, it is clearly desirable to develop a security method which can determine the appropriate access privileges for principals. It is further desirable to provide a security method that allows permissions to change dynamically when code from one source causes the execution of code from another source.
SUMMARY OF THE INVENTION
A method and apparatus for determining the access rights of principals is provided. According to one aspect of the invention, access rights for a principal are determined dynamically based on the source of the code that is currently being executed by the principal (e.g. thread, process)
According to one aspect of the invention, when a request for an action by a thread is detected, a determination is made of whether the action is authorized based on permissions associated with routines in a calling hierarchy associated with the thread. A calling hierarchy indicates the routines (e.g. functions, methods) that have been invoked by or on behalf of a principal (e.g. thread, process) but have not been exited.
In one embodiment, the association between permissions and routines is based on an association between routines and classes and between classes and protection domains. Thus, for example, a first routine may be associated with a first set of permissions, which correspond to the permissions belonging to the protection domain associated with the code source of the first routine's associated class. A second routine may be associated with a second set of permissions, which correspond to the permissions belonging to the protection domain associated with the code source of the second routine's associated class. The determination of whether a particular request is authorized is based on a determination of whether at least one permission associated with each routine in the calling hierarchy encompasses the permission required to perform the requested action. For example, a determination of whether a particular request is authorized is based on determining whether (1) at least one permission from a first set of permissions associated with the first routine in a calling hierarchy encompass the permission required, and (2) at least one permission of a second set of permissions associated with the second routine in the calling hierarchy encompass the permission required.
According to another aspect of the invention, certain routines may be “privileged”. A privileged routine is allowed to perform certain actions even if the routine that called the privileged routine does not have permission to perform those same actions.
According to one embodiment, a flag in a frame in the calling hierarchy corresponding to a privileged routine is set t

Affiliated with

Also associated with

Rating

Controlling access to a resource does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Controlling access to a resource, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Controlling access to a resource will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2615271