Report on 1003.6: Security Extensions

[Peter Collinson]

Submitted-by: pc at hillside.co.uk (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <stephe at usenix.org>, Report Editor
Report on POSIX.6: Security Extensions


Ana Maria De Alvare <anamaria at sgi.COM> reports on the April
15-19, 1991 meeting in Chicago, IL:

Summary

The POSIX.6 group spent the week preparing draft 11 of their document
for internal ``mock'' ballot. They began work on their test assertions
document. The IEEE balloting group formation process is now officially
closed.

The Privilege subgroup discussed a proposal to remove the global
constant POSIX_PRIV_EFFECTIVE from the draft. The Audit subgroup will
not be able to address the portable audit format before balloting
begins, but they will define the audit trail header. The liaison group
between POSIX.6, POSIX.7 (System Administration) and the Distributed
Services groups will report back to the TCOS-SS Sponsor Executive
Committee (SEC) at the July meeting, recommending a new coordination
group be formed.

Report

The POSIX.6 group met for the entire week in Chicago. The group
concentrated their efforts on cleaning up draft 10 of the document.
The balloting solicitation process has been closed.  If you requested
to be in the balloting group, please confirm you are on the list by
calling the IEEE, Anna Kacznarek (908-562-3811).

A major action item was the creation of the test assertions document
for POSIX.6.  This will be a separate parallel document.  The
definitions and overview sections of POSIX.6 were addressed this
week.  Each subgroup will be responsible for creating the test
assertions for the document sections they are working on.  The
subgroups will maintain consistency between the test assertions and
the POSIX.6 document.  Modifications to the POSIX.6 document will
signal modifications to the test assertion document.

In the next meeting we are planning to integrate test assertion
sections from POSIX.3.1 (Test Assertions for POSIX.1) into our
document.  Dave Rogers (Data Logic) and I are co-chairing this
effort.  If you are interested in participating in the test assertion
work, please let me know (anamaria at sgi.com or 415-335-7309).

POSIX.6 will mock ballot draft 11 within the working group before
July.  We plan to review written comments to this mock ballot at the
July meeting.  If all the written comments are addressed, we will try
to ship the document for IEEE ballot after July.  We could then start
resolving the ballot objections at the October meeting.

Privileges

Secureware's VP of Marketing proposed eliminating from the standard
the system global constant, POSIX_PRIV_EFFECTIVE, which turns on/off
all the privileges already set by the process or set by the file
privileges in effect.  The system global constant can increase or
decrease the effective privilege set.

The argument against the system global constant was that when
POSIX_PRIV_EFFECTIVE is on, a privilege aware program (i.e. a trusted
application) will have effective privileges on before it uses them.
This violates the concept of least privilege, since the process
contains more privileges than it needs.  It is the responsibility of
that trusted application to turn off all effective privileges and then
turn them on one by one as it needs them.

Another argument against the global constant is that it gives the
system manager a central point to turn on/off privileges.  With the
new scheme, programs that turn ``priv_effective'' on are consciously
given permission to do so, a point that brings higher granularity.

A vote was taken and the group decided to eliminate the system global
constant, POSIX_PRIV_EFFECTIVE and use ``priv_effective'' as an
additional file privilege.  The standard now contains three privilege
sets associated with a process, (inheritable, permitted, effective)
and two privilege flags (``allowed'' and ``forced'') associated with
each privilege on a file. The two file privilege flags are:

   - Allowed - a flag associated with a file privilege that will
     authorize it to be on during the execution of that program, if
     the process possesses that privilege.

   - Forced - a flag associated with a file privilege that will be on
     during the execution of that program even if the process does not
     possess that privilege.  This allows for old setuid programs to
     continue to work under POSIX.6 without source code modifications.

The new file privilege ``priv_effective'' will turn on the process's
effective privilege set.  If your file has ``priv_effective', your
file makes effective all of the privileges that are on after
calculating ``allowed'' and ``forced'' flags against the process's
inheritable flags.

A process possesses three sets of privilege flags:  inheritable,
permitted, and effective.  For a process to access a file, the
process's effective privilege set (built from its inherited and
permitted sets) is tested against the file's privilege set. To be able
to pass a privilege from the inheritable set (from its parent
process), to the permitted set, the system will test the process's
inheritable privilege against the file's ``allowed'' and ``forced''
flags for that privilege.  If the file privilege's ``allowed'' flag is
set, then the privilege is turned on in the process's permitted set.
If the file privilege's ``forced'' flag is set, then the privilege is
turned on in the process's permitted set even if the privilege was not
inherited.

To be on in the process's effective set, the system compares the
inheritable privilege against the file's ``allowed'', and ``forced''
flags. If the process's inherited privilege is in the file's
``allowed'' set and the file's ``priv_effective'' privilege is set,
then the privilege becomes effective.  If the process's inherited
privilege is in the file's ``forced'' set and the file's
``priv_effective'' privilege is set, then the privilege becomes
effective.  In other words, to be set effective the file's
``priv_effective'' flag must be on.

Some of you might think that this scheme still gives me a trusted
application with effective privileges turned on.  The list of programs
with privileges turned on, however, is smaller than using the system
global constant.  In addition the effective privilege set is not on
for all processes.

All of this can become very confusing.  Sometimes I have trouble
understanding all of the benefits.  Every time I read the document new
questions come to mind.  Sometimes I agree and other times I don't.
Hopefully the mock ballot will call attention to any ambiguous areas
left in the draft document.

Access Controls

Both the discretionary and mandatory access control subgroups (DAC and
MAC) are ready for our internal mock ballot. The primary DAC related
changes for draft 10 concerned default access control list (ACL)
behaviour and the command 
	chacl
which changes the ACL.  The MAC group had no hot issues to discuss.


1.  Audit

The Audit group finished modifying the draft and writing the rationale
for integrity protection, header flexibility, and cross references.
The group felt they cannot address the portable audit format before
balloting, however, they are planning to define the audit trail header
containing:

   - POSIX audit indicator field,

   - version ID,

   - data format indicator (type XDR, little endian, big
     endian),

   - time zone offset,

   - machine id, and

   - audit style.
The audit file format remains up in the air.

POSIX.6/POSIX.7/Distributed Services Liaison

The liaison group met on Wednesday.  Mike Ressler stepped down and I
became the chair of the group.  We discussed the status of the group
and what we should bring forward to the TCOS-SS Sponsor Executive
Committee (SEC). Everyone agreed that we have enough information to
create a report to the SEC discussing the problems we discovered and
to make recommendations.

I will present our report at the July meeting with the help of the
liaison group.  The report will include an overview of each subgroups
objectives, a list of problem areas discovered during our meetings,
and recommendations to solve these problems.  I hope that SEC acts
upon our recommendations.

One recommendation we want immediate action on is the lack of a
mechanism to ensure that one POSIX extension can interoperate with
another POSIX extension.  An example of this interoperability issue is
having POSIX.6 and POSIX.8 (Transparent File Access) on the same
system.  We are proposing a new group be formed which will check that
POSIX standards interoperate with each other or to at least document
where different POSIX extensions cannot interoperate.


Volume-Number: Volume 24, Number 29