Browse Prior Art Database

Administrative Role Configuration with Privilege Control Lists

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

Publishing Venue

IBM

Related People

Langford, JS: AUTHOR [+3]

Abstract

Disclosed is a design for a mechanism for defining administrative roles which allow for full configuration of such roles by the local system administrator. An administrative role in an operating system is effectively defined by the ability to execute commands with privilege.

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

Administrative Role Configuration with Privilege Control Lists

      Disclosed is a design for a mechanism for defining
administrative roles which allow for full configuration of such roles
by the local system administrator. An administrative role in an
operating system is effectively defined by the ability to execute
commands with privilege.

      UNIX* systems in the past have allowed only monolithic
privilege with respect to command execution. Either a user was fully
privileged or had no privilege at all. Worse, a user who was fully
privileged for one command would need to be fully privileged for all
commands. This mode of privilege is an obvious violation of the Least
Privilege Principle. It is commonly termed 'superuser' privilege,
because administrative privilege in the system is associated with
only one user - the superuser.

      The use of protected subsystems in UNIX, via the setID
mechanism, ameliorates this to a degree. With this mechanism, the
access rights and privileges of the superuser may be associated with
a program. When executed by a user with execute permission for the
file, the program acquires the privileges of the superuser and may
perform administrative actions on behalf of the user. This type of
mechanism is termed a protected subsystem because the program has
greater privilege than its invoker, and can enforce constraints upon
the use of that privilege.

      This mechanism is still problematic, though, simply because
full privilege is granted indiscriminately to all users with execute
permission for the program file. If programs were designed as units
of administrative function, this would not present a problem. But it
is the case that for many commands in the system, different users
require different privileges for these commands.

      There appear to be two sorts of commands which require
differing levels of privileges. The first of these are normal,
everyday system commands which must be executable by all users, but
which must be privileged for administrators. For an example, consider
ls, the command which reads and displays directory information.
Normal users may use this command to access the directory information
for their own directories and for directories for which they have
been given search permission. But many administrators require the
ability to search through all directories, and so must have privilege
when executing this command. As another example, the tar (tape
archive) program is used for file archival, file exchange and to move
directory subtrees in the system. Normal users use this command on
their own files, primarily, but the system operator must have the
ability to access every file in the system with this command. And the
system security administrator must have the ability to import
privileged files using tar.  Consequently, for tar there are not only
different privileges for users and administrators, but different
privileges for different classes of administrator...