Path: utzoo!attcan!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 5: 1003.6
Message-ID: <338@longway.TIC.COM>
Date: 11 May 89 15:39:41 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 159
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update Part 5: 1003.6
An update on UNIX|= Standards Activities
January 1989 IEEE 1003 Meeting, Ft. Lauderdale
Part 5: 1003.6
Shane P. McCarron, NAPS International
1003.6 - Security Extensions to POSIX
The security working group is currently working on a
number of topics in parallel - Autiding, Discretionary
Access Controls (DAC), Mandatory Access Controls (MAC), and
Privileges. As these topics have been described in detail
in previous installments, I won't do it again. Instead,
here is a brief summary of topics of interest being
discussed in those sub-committees:
MACs
The group decided to accept one proposal before them as
a baseline. This will help them to decided on their exact
scope of operation and also to decide on their goals. This
baseline proposal has not solved even a small percentage of
the problems facing this committee. Things like information
label mechanisms, data transport, text label format, label
constraints, and security for public/shared directories were
too abstract at this time, the group decided to ask for
white papers to talk about them at the April meeting.
AUDIT
This group has embraced a proposal as a base. This
proposal, in conjunction with a proposal from X/Open, will
probably be the primary source in this area.
DAC
This group was finally able to resolve some of the
issues that have been in dispute since its creation. In
particular, the group was able to agree on: The
representation of an Access Control List (ACL), Ordering,
Default ACLs, and most importantly the issue of how ACLs are
to be used in the system. ACLs will be an additional
security mechanism, which much be enabled by explicit user
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
January 1989 - 1 - Ft. Lauderdale
Standards Update Part 5: 1003.6
action. This satisfies the requirements of the 1003.1
standard, which had left room for just such a mechanism by
leaving some weasel-wording in the definition of File Group
Class. The specific mechanism will be that the permissions
available to users (or groups) listed in an ACL will be a
subset of those availabe using the traditional group
permissions of the file.
In addition, the inheritance of ACLs was discussed. It
appears as if the group will agree that the ACL for a
directory will propogate to any sub-directories that are
created. However, this is still an issue and will be
debated at the April meeting.
In addition, the group agreed that there will be
routines in the standard for manipulating each type of ACL,
and that named or shared ACLs will not be in the standard.
PRIVILEGES:
The principle of least privileges requires that each
subject in a system be granted the most restrictive set of
privileges needed for performance of authorized tasks. The
principle of Least Privilege will also include the concept
that each privilege is available for the minimum scope of
execution required to perform the task for which it is
needed.
The purpose of privileges is to assure the authorized
and restricted use of a service. Security relevant code can
be bracketed and the privileges may be enabled only during
execution of that part of a program.
Issues that need to be addressed by this group include:
1. To what degree can privileges be segmented to allow
control over individual privileged actions?
2. How can a designer of a privilege propagation
mechanism assure compliance with the principle of
least privilege?
3. How can user access to privileged operations be
limited in accordance with the principle of least
privilege?
4. What control interfaces are necessary to allow
privilege mechanism?
The group has agreed that no privilege should grant access
to more than a single set of related operations. The group
January 1989 - 2 - Ft. Lauderdale
Standards Update Part 5: 1003.6
also agreed that the propogation of a privilege from one
"subject" (process) to another should be strictly
controlled. Because traditional implementations propogate
priviliege based on the effective user ID of a process, any
secure implementation will have to permit this behavior.
However, to permit for more secure software being developed
in the future, it is necessary to provide some primitives
that will permit a parent process to restrict which
privileges are progated to its children.
The standard will be defining a set of interfaces for
accessing privileged operations. These interfaces will
allow for: Reducing the level of privileges, setting,
creating, or adding privileges, acquiring privineges,
testing for privileges, requesting a privilege type, setting
privilege propogation, requesting a set of maximal
privileges, determining the set of privileges currently
enabled, determining the success or failure of privilege
accumulation, and creating of privileges not in the current
set.
The scope of this committee is to define extensions to
the POSIX interface which support a privilege mechanism
capable of enforcing a 'Least Privilege' security policy,
and a minimum set of privileges which are necessary to
support such a policy in a portable applications
environment.
The Usenix Standards Watchdog Committee contact for
this group is Anna Maria de Alvare. She can be reached at:
Anna Maria de Alvare
Lawrence Livermore National Laboratories
PO Box 808
L-303
Livermore, CA 94450
+1 (415) 422-7007
annama...@lll-lcc.llnl.gov
uunet!lll-lcc.llnl.gov!annamaria
January 1989 - 3 - Ft. Lauderdale
Volume-Number: Volume 16, Number 36
|