Browse Prior Art Database

Compatibility of a Granular Privilege Mechanism with Setuid Programs

IP.com Disclosure Number: IPCOM000107500D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 3 page(s) / 129K

Publishing Venue

IBM

Related People

Langford, JS: AUTHOR [+3]

Abstract

Disclosed is a design for providing compatibility with setuid root programs while using a granular, non-user ID-based privilege control mechanism. Compatibility with existing programs is always a major concern when extending the security of a system, so as to provide a graceful migration path.

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

Compatibility of a Granular Privilege Mechanism with Setuid Programs

       Disclosed is a design for providing compatibility with
setuid root programs while using a granular, non-user ID-based
privilege control mechanism. Compatibility with existing programs is
always a major concern when extending the security of a system, so as
to provide a graceful migration path.

      Protected subsystems are a key component of secure systems.
They allow privilege to be associated with a program instead of a
user, so that the use of privilege may be confined to a few, testable
programs on the system. Understandably, then, protected subsystems
provide far greater security than assigning privileges directly to a
user.

      In normal UNIX* systems, protected subsystems are implemented
as setuid programs. The setuid mechanism works by allowing program
files to be tagged as setuid. When a setuid program is executed by a
process, the process acquires the access rights and privileges of the
owner of the file. When a program owned by the single privileged user
(known as "root" or "superuser") is tagged as setuid, this program
becomes a protected subsystem because it will acquire full privileges
when executed. Such programs are termed "setuid-root" programs.

      To provide compatibility with setuid programs requires that the
programming interface for privilege manipulation be preserved. This
programming interface consists of the system call setuid(). With this
system call, the process may perform the following logical functions:
         - PRIVILEGE LAPSE
                 the process sets its privilege state to that of its
invoker
         - PRIVILEGE ACQUIRE
                 the process sets its privilege state to that of the
protected subsystem
         - PRIVILEGE DROP
                 the process sets its privilege state to a new state
and drops the privileges of its invoker and any acquired privileges.

      In order to accomplish this with the standard setuid-root
Protected Subsystem mechanism, the process will manipulate its user
IDs.  Each process in a UNIX system has 3 user IDs. These are the
real, effective and saved user IDs. The real user ID is that of the
user who invoked the program, and so defines the access rights and
privileges of the invoker. The saved user ID, if different from the
real user ID, will be that of the last protected subsystem executed
by the process, and so will define the acquired access rights and
privileges. The effective user ID will be equal to either the real or
saved IDs, and so defines the correct privilege state of the process.

      In order for a setuid-root program to LAPSE its privileges, the
program sets its effective user ID to the value of its real ID. To
ACQUIRE full privilege, the setuid-root program sets its effective
user ID to the value of its saved user ID. And to DROP privilege, the
setuid-root program...