Least privilege via restricted tokens

Details Least privilege via restricted tokens Least privilege via restricted tokens

1998-06-12

2001-10-23

Lee, Thomas (Department: 2182)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Protection at a particular protocol layer

C713S152000, C713S169000, C713S159000, C713S172000, C713S173000, C713S170000, C710S200000, C710S220000, C710S241000, C710S242000, C710S243000, C710S244000

Reexamination Certificate

active

06308274

ABSTRACT:

FIELD OF THE INVENTION
The invention relates generally to computer systems, and more particularly to improvements in security for computer systems.
BACKGROUND OF THE INVENTION
In computing, if a task is performed by a user having more privileges than necessary to do that task, there is an increased risk that the user inadvertently will do some harm to computer resources. By way of example, if a set of files can only be deleted by a user with administrator privileges, then an administrator may inadvertently delete those files when performing another task that does not need to be accomplished by an administrator. If the administrator had been a user having lesser privileges, then the intended task could still have been performed but the inadvertent deletion would not have been allowed.
Thus, a recognized goal in computer security is the concept of least privilege, in which a user performing a task should run with the absolute minimum privileges (or identities, such as group memberships) necessary to do that task. However, there is no convenient way to add and remove a user's access rights and privileges. For example, in the Windows NT operating system, when the user logs on, an access token is built for the user based on the user's credentials. The access token determines the access rights and privileges that the user will have for that session. As a result, the user will have those privileges for each task attempted during that session and for any future sessions. While ideally an administrator can set up multiple identities and log-on as a different user with different rights for each task, this is too burdensome and too complicated. Moreover, since there is no automatic enforcement, even a safety-conscious administrator is unlikely to log off and log back on with a new identity each time a different task is performed, simply to avoid the possibility of doing some unintended action.
In short, there is simply not a convenient way to change privilege levels or access rights, nor a way to further restrict privileges at a granularity finer than that created by the domain administrator. Other operating systems have similar problems that make running with least privileges an ideal that is rarely, if ever, practiced.
SUMMARY OF THE INVENTION
Briefly, the present invention provides a mechanism to enforce least privilege, or in some way reduced access, via restricted access tokens. Restricted access tokens enable a security mechanism to determine whether a process has access to a resource based on a modified, restricted version of an existing access token. The restricted token is based on an existing token, and has less access than that token. A restricted token may be created from an existing (parent) token by changing an attribute of one or more security identifiers that allow access in the parent token to a setting that denies access in the restricted token and/or removing one or more privileges from the restricted token that are present in the parent token. In addition, restricted security identifiers may be placed in the restricted token.
In use, a process is associated with a restricted token, and when the restricted process attempts to perform an action on a resource, a kernel mode security mechanism first compares the user-based security identifiers and the intended type of action against a list of identifiers and actions associated with the resource. If there are no restricted security identifiers in the restricted token, access is determined by the result of this first comparison. If there are restricted security identifiers in the restricted token, a second access check for this action compares the restricted security identifiers against the list of identifiers and actions associated with the resource. With a token having restricted security identifiers, the process is granted access to the resource only if both the first and second access checks pass.
Application programs may have restriction information stored in association therewith. When the application is launched, a restricted token is created for that application based on the restriction information. In this manner, reduced access is automatically enforced for that application. Applications may be divided into different access levels such as privileged and non-privileged portions, thereby automatically restricting the actions a user can perform via that application. Also, the system may enforce running with reduced access by running user processes with a restricted token, and then requiring a definite action by the user to specifically override actions that are restricted by temporarily running with the user's normal token.


REFERENCES:
patent: 4962449 (1990-10-01), Schlesinger
patent: 5138712 (1992-08-01), Corbin
patent: 5276901 (1994-01-01), Howell et al.
patent: 5321841 (1994-06-01), East et al.
patent: 5390247 (1995-02-01), Fischer
patent: 5412717 (1995-05-01), Fischer
patent: 5506961 (1996-04-01), Carlson et al.
patent: 5542046 (1996-07-01), Carlson et al.
patent: 5638448 (1997-06-01), Nguyen
patent: 5649099 (1997-07-01), Theimer et al.
patent: 5675782 (1997-10-01), Montague et al.
patent: 5678041 (1997-10-01), Baker et al.
patent: 5680461 (1997-10-01), McManis
patent: 5682478 (1997-10-01), Watson et al.
patent: 5745676 (1998-04-01), Hobson et al.
patent: 5757916 (1998-05-01), MacDoran et al.
patent: 5761669 (1998-06-01), Montague et al.
patent: 5812784 (1998-09-01), Watson et al.
patent: 5826029 (1998-10-01), Gore, Jr. et al.
patent: 5845067 (1998-12-01), Porter et al.
patent: 5922073 (1999-07-01), Shimada
patent: 5925109 (1999-07-01), Bartz
patent: 5940591 (1999-08-01), Boyle et al.
patent: 5941947 (1999-08-01), Brown et al.
patent: 5949882 (1999-09-01), Angelo
patent: 5983270 (1999-11-01), Abraham et al.
patent: 5983350 (1999-11-01), Minear et al.
patent: 6081807 (2000-06-01), Story et al.
patent: 6105132 (2000-08-01), Fritch et al.
patent: 0 398 645 (1990-11-01), None
patent: 0 465 016 (1992-01-01), None
patent: 0 588 415 (1994-03-01), None
patent: 0 697 662 (1996-02-01), None
patent: 0 813 133 (1997-12-01), None
patent: WO 96/05549 (1996-02-01), None
patent: WO 96/13113 (1996-05-01), None
patent: WO 97/15008 (1997-04-01), None
patent: WO 97/26734 (1997-07-01), None
Frost, Jim “Windows NT Security”, May 1995, pp. 1-5, retrieved on Jun. 27, 2001 from the Internet <http://world.std.com/~jimf/papers
t-security
t-security.html>.
Asche, Ruediger R. “Windows NT Security in Theory and Practice”, May 1995, pp. 1-14, retrieved on Jun. 27, 2001 from the Internet:<http://msdn.microsoft.com/library/techart/msdn-seccpp.htm>.
Asche, Ruediger R. “The Guts of Security”, May 1995, pp. 1-26, retrieved on Jun. 27, 2001 from the Internet:<http://msdn.microsoft.com/library/techart/msdn_secguts.htm>.
Soshi et al. “The Saga Security System: A Security Architechture for Open Distributed Systems”, IEEE, 1997, pp. 53-58.*
“Java Security Model: Java Protection Domains,” http://java.sun.com/security/handout.html, printed Nov. 11, 1999.
Anon, “Privilege Control Mechanism for UNIX Systems,”IBM Technical Disclousure Bulletin, vol.34, No. 7b pp. 477-479, Dec. 1991.
Erdos et al., “Security Reference Model for the Java Developer's Kit 1.0.2,”Java Security Reference Model, Nov. 13, 1996, http://www.javasoft.com/security/SRM.html printed Jul. 14, 1999.
Fritzinger et al., “Java Security,”1996, http://java.sun.com/security/whitepaper.txt.
Mazieres, David and M. Frans Kaashoek, “Secure Applications Need Flexible Operating Systems,”6th Workshop on Hot Topics in Operating Systems (HotOS-VI), May 5-6, 1997, http://www.eecs.harvard.edu/hotos/.
Goldstein, Ted, “The Gateway Security Model in the Java Commerce Client,”The Source for Java ™Technology, 1997, http://www.java.sun.com/products/commerce/docs/whitepapers/security/JCC_gateway.html printed Jul. 14, 1999.
Mazieres, David and M. Frans Kaashoek, “Secure Applications Need Flexible Operating Systems,”6th Workshop on Hot Topics in Operating Systems (HotOS-VI), May 5-6, 1997, http://www.eecs.harvard.edu/hotos/.
Neuman et al., “Kerberos: An Authentication Servic

Affiliated with

Also associated with

Rating

Least privilege via restricted tokens does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Least privilege via restricted tokens, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Least privilege via restricted tokens will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2580922