Standards Update, IEEE 1003.6: Security Extensions

[Jeffrey S. Haemer]

From: Jeffrey S. Haemer <jsh at usenix.org>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare <anamaria at lll-lcc.llnl.gov> reports on the October
16-20, 1989 meeting in Brussels, Belgium:

The security working group worked the full week, discussing the draft.
The meeting's primary goal was to approve the current draft for
distribution to the international working groups. It was presented, at
the EEC, to new members of the group from the European countries, and
every member introduced himself/herself the first day of the meeting.
Once introductions were out of the way, we dealt with the major topics
that follow.

TRUSIX

A representative from TRUSIX, Charles Testa, gave the usual progress
report on TRUSIX.  [Editor's note -- TRUSIX is an organization
sponsored by the National computer security center (NCSC), developing
a secure UNIX model.  The participants are a number of vendors
developing secure UNIX implementations.] Their modeling subcommittee
has nearly completed a formal model describing the UNIX file system.
They have accepted the "Ina Jo" model to describe Trusted UNIX System
Interfaces.  This model revolves around a MAC-read criterion, MAC-
writes and a DAC constraint, and consists of simple security
properties, confinement properties, and discretionary security
properties representative of the Bell-LaPadula model.

The TRUSIX ACL Rationale and Working Example Document has been
approved by the NCSC and is being reviewed for publication under NCSC
security publications.

One topic of interest to all security readers is prevention and/or
detection of covert channels.  TRUSIX is planning to include this
under the Audit Rationale Document, which will include examples of
typical covert channels and their implications.  Issues such as

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 2 -

bandwidth evaluation will be addressed by a separate white paper.

POSIX Conformance Testing

A representative from 1003.3,the POSIX Conformance Testing group,
presented 1003.3's goal -- to establish a series of specifications for
testing the different POSIX standards. Although they have written the
pseudo-code to test the conformance of a system to 1003.1, they feel
they lack the staff and expertise to produce such tests for all the
1003 groups.  Given this, their current plan is to draw upon each
group for expertise and background knowledge of the subject at hand,
and join those skills with their testing skills to produce a test bed
for each 1003 standard.

Their ultimate goal is to allow testing of all elements of an open
system for POSIX conformance by defining common test methods, which
can then be implemented by private industries as test suites. They
explained how to list the assertions, how to classify them, and what
information they will need to produce a test method for 1003.6.

One factor mentioned was that the description has to address a single
unit of behavior expected of a conformant system at a time. This
implies dissecting interfaces into separate groups of assertions and
generating assertions for both semantic and syntactic descriptions.

Discretionary Access Control (DAC)

The group focused on polishing and adding information to the draft.
It was suggested the standard shouldn't define the behavior of 'chmod'
when old programs are being executed with the DAC mechanism.

It was noted that the current proposed Access Control List (ACL) might
not be fully compatible with the current behavior of a 'chmod' call.
With the current, old-style behavior, when 'chmod' is used to change
owner, group and/or other permissions, the changed permissions
represent the access modes of the file.  In the current proposal for
ACL, a 'chmod' will provide the old behavior for the "owner" and
"other" fields, but the "group" field permissions as set by 'chmod'
and shown by 'stat', wouldn't represent the actual access permissions
of the group associated with that file; instead, it's a summary of all
access permissions included under the ACL list for group entries.  In
other words, it would represent the maximum permissions allowed to the
group entries included in the ACL list.

Some participants argued that 'chmod' should be replaced by other
system calls in a system conforming to 1003.6.  In other words, if
your system were to conform to 1003.6 the behavior of chmod would be

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 3 -

unspecified and unpredictable.

I disagree.  Although defining the behavior of 'chmod' might restrict
some implementations of ACLs, having a well-defined chmod behavior
will provide backward compatibility and ease porting old programs to
1003.6-conformant systems.  Otherwise old programs will have to be
ported to platforms with system-dependent representations of 'chmod'
and 'stat' information.

It was also proposed that the ACL list should allow entry types like
timestamping.  This would allow a policy that is more restrictive than
the DOD, orange-book policy to provide more granularity of file
access.

Mandatory Access Control (MAC)

Kevin Murphy, of British Telecom, presented his views on electronic-
mail-label usage and proposed that such a mechanism should be used as
part of the standard.  The electronic mail security labels consist of
a generic format that includes four major components: security policy
id, security classification, privacy mask, and security categories.
This approach to labels is implemented on X.400 security services.
One clear advantage of using such a format for labels is that it
maximizes the potential synergy between operating-system and
electronic-mail labels.

Chris Hughes from ICL presented British views on MAC information
labels.  Its main characteristics are these: object creation
initializes the label, the label is implementation-defined and changed
by the owner, and the label is not used for access control.  Chris
proposed that the standard should provide a get/set mechanism for the
object information label, and a way to merge and translate information
labels, but should not standardize the labels' contents.

Information labels are useful because they provide added information
on particular objects.  We concluded that information labels should be
in the scope of MAC as part of the standard, and requested that MITRE
provide a presentation on information label use at the next meeting.

Privileges

The whole group heard a presentation of the internal draft of the
privileges document.  We decided that the wording had problems.  The
draft interface description is too obscure and needs a simpler
description of privilege interfaces, before it can be included in the
1003.6 draft document.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 4 -

Although the group argued considerably about the wording, they seemed
to agree on the concepts.  The main points are that privilege is
associated with a process and privilege attributes can be attached to
files.

I do not think I should burden the reader with the brainstorming ideas
of the privilege group until a firmer position is taken at the next
meeting.  One thing I can say is that the process-privilege concepts
described in my last report (permitted, inheritable and effective),
still stand, and a file still has three types of privilege attributes.

Audit

Kevin Brady from AT&T and Doug Steves from IBM presented a combined
proposal, produced by them and Henry Hall from DEC, on how to define
audit interfaces for 1003.6.  Their proposal was meant to contest the
current audit stand, lead by Olin Sibert from Oxford Systems.

The current audit definition is based on the token concept and on a
pure procedural interface.  In the procedural interface all data
manipulation of the audit record is performed by function calls, with
data passed explicitly through function parameters.  Although this
sounds attractive and clear, in practice it requires many function
calls.

Another major point of controversy was the audit trail format.  In
Olin's proposal, conversion cost is minimal because writes and reads
require an explicit specification of the format wanted.  In Kevin,
Doug and Henry's proposal the conversion function is set to one of
three conventional formats: little endian, big endian, or XDR.  In
other words, the information is stored in machine-dependent format
while Olin's chooses a uniform format for all information stored.

One last contested feature was the ability to rewind audit trail
information when viewing it.  Kevin, Doug and Henry's proposal does
not allow a rewind, since information is manipulated at the data-
structure level.

Because of the heated discussion of procedural versus data-structure
interfaces for POSIX, both proposals will be formally written out,
removed from the draft, and presented in the next meeting for a final
vote.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 94