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
Lines: 159
Approved: (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:


     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.


     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.


     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.


     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

     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

  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

     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

     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
          Livermore, CA  94450
          +1 (415) 422-7007


January 1989               - 3 -              Ft. Lauderdale

Volume-Number: Volume 16, Number 36

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.