Dismiss
InnovationQ will be updated on Sunday, Jan. 21, from 9am - 11am ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Logically Extensible Privilege Control Set

IP.com Disclosure Number: IPCOM000122570D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 168K

Publishing Venue

IBM

Related People

Steves, DH: AUTHOR [+2]

Abstract

Disclosed is a design for a Privilege Set to be used in an operating system which enforces the Least Privilege Principle. This Privilege Set is designed to be logical, so that it may be easily understood and used, and extensible, so that the system may be extended using the existing set of privileges.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 32% of the total text.

Logically Extensible Privilege Control Set

      Disclosed is a design for a Privilege Set to be used in
an operating system which enforces the Least Privilege Principle.
This Privilege Set is designed to be logical, so that it may be
easily understood and used, and extensible, so that the system may be
extended using the existing set of privileges.

      The Least Privilege Principle requires that the components of
the Trusted Computing Base be assigned the minimal privilege
necessary to perform the function for that component. In traditional
UNIX* operating systems, these components consist of the kernel and
the administrative programs. The kernel, of course, has full
privilege, and this cannot be minimized without fully restructuring
the system. The administrative programs (termed Trusted Processes)
are normally installed with full privilege as well. This is not
necessary for structural reasons, but is done only because the
existing privilege mechanism is binary. Either a Trusted Process (TP)
is fully privileged or it is fully unprivileged.

      This problem has been addressed in many operating systems,
usually in one of two ways. The first method is to provide
hierarchical, role-based privileges, and assign these to users. These
privileges are acquired by all application programs run by these
users. This approach does not provide least privilege for exactly
that reason. Since all programs acquire the user's privileges,
without regard to need, many programs will be run with excessive
privileges.

      This scheme has been modified so that the privileges may be
directly associated with the programs which require them, but this
approach does not quite solve the problem, since the privilege set
itself was designed for users, not for programs.

      The second approach involves assigning privileged actions to
discrete privileges. One way that this has been done is to identify
all privileged interfaces (system calls which require privilege) in
the system and associate a privilege with each such interface. There
are many problems with this. First, the number of privileged
interfaces in the system grows over time, which would cause the
number of privileges to become quite large. This would make it very
difficult to administer the system. Secondly, the privileged
interfaces in the system are inconsistently defined, and so the
privilege set will be inconsistent as well. As an example of this,
consider the operations to change the owner of an object, change the
mode of an object and to remove an object entirely. For filesystem
objects, these are done through discrete interfaces and so require
separate privileges. For interprocess communication objects, there is
only one interface and so only one privilege. It is difficult to
claim Least Privilege with inconsistencies like this. Lastly, the
privileges are defined in terms of low-level interfaces with which
the average administrator may not be familiar. Since the system
admin...