Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v20/repdir/1003.6

Internet Message Format | 1990-08-02 | 15KB

From [e-mail]  Thu Jun 28 16:59:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28596; Thu, 28 Jun 90 16:59:49 -0400
Posted-Date: 28 Jun 90 18:20:43 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA19186; Thu, 28 Jun 90 15:59:39 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06448; Thu, 28 Jun 90 15:04:01 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 18:20:43 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security

An anonymous source reports on the April 23-27 meeting in Salt Lake
City, UT:

Apologia

This is my first and last review as a snitch.  [ Editor: We thank you
for doing it, and hope your circumstances change to allow you to file
more.  ] In it, you'll see no party line.  My views will sometimes be
controversial, and I hope they spark discussion and feedback.  They
represent neither the views of my company nor of its clients -- I'm
submitting this anonymously so no one can misconstrue them as being my
company's -- and they're certainly not meant to represent the
consensus of the 1003.6 Working Group.

I'll put my biases on the table.  I'm a commercial user and commercial
software provider, not a government user, government software
provider, or UNIX vendor.  To some degree, these biases have
influenced the committee, since I've been active in the group since
its inception and attended every 1003.6 meeting.  With that
perspective, let's begin.

1.  Overview

The 1003.6 Working Group is putting together a Department-of-Defense-
inspired version of UNIX.  Our efforts will help vendors sell systems
to the U.S. Government and its contractors.  All our interfaces will
make it easier to evaluate conforming systems at one of the DoD's
Trusted Computer Security Evaluation Criteria (TCSEC) levels.  This is
not inherently bad, but it does sell the commercial and international
communities short.  (More on this later.)

The working group is considering four areas: Discretionary Access
Control (DAC), Mandatory Access Control (MAC), Least Privilege, and
Audit.

__________

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

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 2 -

1.1  Discretionary Access Control

The DAC group's job is hard.  They are devising an Access Control List
(ACL) mechanism that must co-exist with the familiar user/group/other
mechanism.  ACLs are discretionary because the user, not the system,
decides each object's access rights.  The traditional user/group/other
mechanism is also discretionary: file protections are specified by the
user.  ACLs extend this by allowing users to grant different access
permissions to arbitrary lists of named users and groups.  (In other
words, the traditional mechanism is an ACL with exactly three
entries.) Designing an ACL is easy; maintaining compatibility with
chmod, stat, umask, and the file creation mask of creat isn't.

1.2  Mandatory Access Control

MAC is another type of access control mechanism.  All system objects
get a security label and all system users have a security
classification set by the system or the Security Administrator
(Systems Administrator).  Users have no control over this mechanism's
application; objects created by a user of classification X
automatically receive a security label of X.  Only users with
appropriate classifications can access or modify a system object.  (As
a useful, if inexact, analogy, think of the way UNIX automatically
assigns file ownerships.)

The TCSEC security criteria's popularity and widespread acceptance
have given MAC another connotation -- that of a codification of the
familiar, U.S.-government, hierarchical security classifications: Top
Secret, Classified, and Unclassified.  Government policy prohibits
users of a lower classification from viewing work of a higher
classification.  Conversely, users at a high classification may not
make their work available to users at a lower classification: one can
neither ``read up'' nor ``write down.'' There are also compartments
within each classification level, such as NATO, nuclear, DOE, or
project X.  Access requires the proper level and authorization for all
compartments associated with the resource.  The MAC group is defining
interfaces for such a mandatory mechanism.  It's not as confusing as
it sounds, but outside of the DoD it is as useless as it sounds.
(Prove me wrong.  Show me how this DoD policy is useful in a
commercial environment.)

1.3  Least Privilege

The Least Privilege group is eliminating root.  They're creating both
a list of privileges to encompass all of root's special uses, (e.g.,
set-uid to a different user-id, create a directory, create a file
system, override DAC protection) and a mechanism to inherit, assign,
and enable those privileges.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 3 -

1.4  Audit

The Audit group is preparing a standard interface for a logging
mechanism, a standard format for logging records, and a list of system
calls and commands to log.

2.  Standards

At the ISO level, there will be no separate security standard.  Our
work will be merged with the 1003.1 (System Interface), 1003.2
(Commands and Utilities), and 1003.7 (System Administration) work in
the ISO 9945-1, -2, and -3 standards.  This means every conforming
system will include security mechanisms.  I like this.  Do you?

3.  Scope and motivation

All 1003.6 members feel we are making POSIX secure, not merely helping
sell systems to the U.S. government.  Our work is important and
necessary (except, of course, MAC), but I think our focus has been too
narrow.  We included mechanisms for the TCSEC criteria but stopped
there.  We haven't sought out the work of other countries.  We haven't
considered the work being done in international standards bodies such
as ISO and CCITT.  We haven't explicitly considered commercial users.
We've limited ourselves to helping provide TCSEC-conforming systems.
Many of us believe that the TCSEC criteria are good for commercial
applications.  Is that hopeful claim just self-serving?  We don't
know.  I wish eminent computer scientists and researchers had gotten
together to study the needs of commercial users and drawn up an
independent set of commercial security requirements.  But they didn't.

Kevin Murphy, of British Telecom, is the ISO/IEC JTC1/SC22/WG15
security rapporteur -- he formally represents the international
community's concerns and views.  In January, Kevin brought several of
these to the working group's attention, including our TCSEC biases and
lack of attention to ISO activities.  The international set seems to
consider the document's constant references to the TCSEC work
provincial and inconsiderate of other countries' requirements.  They
also feel we should be more aware and accepting of ISO terminology in
the document.  Kevin also says our scope is too limited in the CCITT
X.400 and X.500 areas.

4.  Snowbird

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 4 -

4.1  Plenary

The meeting opened with a short plenary session.  This time, the first
topic of discussion was the progress of the 1003.6 draft document.
Mike Ressler, of Bellcore, accepted the position of technical editor
and brought a new draft of 1003.6, which contained work of all but the
Audit subgroup.  In addition, an electronic copy of the document was
available for the subgroups to modify and update during the meeting.
The technical editor position had been open since October.  No draft
was available during this time, which worried us since it prevented us
from setting any realistic completion date.  With a draft in hand and
a technical editor we now project completion in April, 1991.

Charlie Testa's absence meant we lacked our usual, detailed report on
TRUSIX.  (TRUSIX is a DoD-sponsored organization made up of the
National Computer Security Center, AT&T, and several other companies.)
Rick Sibenaler and Shaun Rovansek, of the NCSC, gave us a brief
update, reporting that the audit rationale will be available at the
July POSIX meeting and that select experts are now reviewing the draft
version of their formal model, which is written in a formal
verification language, INA JO.

Some of the work of TRUSIX augments the work of 1003.6 --  pursuit of
a formal security model and descriptive, top-level specification, and
a mapping between them, for example -- but some overlaps.  I'm still
puzzled over why TRUSIX has pursued audit and DAC mechanisms when
1003.6 is doing the same work.  (Another challenge: can anyone out
there tell me?) To their credit, TRUSIX is accomplishing their goals
much faster than 1003.6.  For example, Charlie reported in January
that the TRUSIX DAC work is already complete.  This speed may be at
the expense of POSIX, since many very good people in both
organizations are forced to split time between the two unnecessarily.

Mike Ressler reported on the networking/administration/security
liaison group, which spends an afternoon at every POSIX meeting
discussing mutual concerns of these three independent working groups.
Here are the liaison group's goals, in areas of our common interest:

   + identify areas of overlapping or missing coverage,

   + provide an interface to ISO, ECMA, CCITT, and other international
     bodies, and

   + exchange ideas and discuss related issues.

Peter Cordsen, of DataCentralen (Denmark), presented Danish security
requirements.  They define three levels of sensitivity, with criminal
data among the most sensitive.  There was no specific comparison to
either the U.S. TCSEC or the emerging European security criteria.
Peter suggested that the security working group begin addressing
authentication, a position that received much support from other
representatives.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 5 -

4.2  Draft work

After the plenary, we worked on the document in subgroups.

4.2.1  Discretionary_Access_Control_(DAC)  The group put together a
new outline for the general and introductory sections of the draft and
rewrote those sections to follow the new outline.  They also resolved
several issues:

   + There will be only one type of default ACL, not the previously
     planned separate types for regular files and directories.

   + A mask entry type has been added to provide a mechanism that
     temporarily overrides all other entries without actually changing
     their values or deleting them from the ACL.  The feature also
     fits nicely with the current plan for ACL interaction with the
     old POSIX permission bits.

   + The user model for both default and actual ACLs will be the same.
     (The internal representations are undefined.) System interfaces
     will be the same, too.  A flag will be added to any interfaces
     that need to be able to distinguish the two.

4.3  Audit

Olin Sibert, of Sun, presented a new, ``compromise'' audit proposal,
based on an earlier one by Kevin Brady, of AT&T, and Doug Steves, of
IBM, which he thought resolved some of the earlier work's problems.
The working group accepted Olin's proposal with minor changes and
incorporated it into Draft 6, which was distributed in the IEEE May
mailing.

4.4  Mandatory Access Control (MAC)

Since Kevin Brady, the MAC chair, was participating in the Audit
discussion, and Chris Hughes, of ICL, the acting chair, was also
absent, Joe Bulger, of NCSC, ran the meeting.  It is still unclear who
will chair the MAC subgroup.

Through the joint efforts of Bellcore and AT&T, the MAC draft had been
translated from a proprietary, word-processor format into the
[n|t]roff + POSIX-macro format required for inclusion in the draft
standard.  The MAC draft's contents had been stable for several
meetings, so the group spent the entire week changing the document.

This group seems to be having the most difficulty getting its job
done.  There doesn't seem to be as much discussion and active
participation in the MAC group as the others.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 6 -

4.5  Privileges

No functional changes were made to the privileges material at this
meeting, but significant changes were made to the rationale.  The
group also firmed up concepts and disambiguated functional
ambiguities.

4.6  Networking, Administration, and Security Liaison

The networking/administration/security liaison group held its second
meeting Wednesday afternoon.  The meeting, chaired by Mike Ressler,
started by reviewing the group's scope and goals.

Since there had been no ISO meeting since the January POSIX meeting,
Yvon Klein, of Group Bull (France), didn't have anything new to say
about ISO's security activities.

As part of the group's continuing efforts to and identify problem
areas, the system administration group and two networking groups gave
presentations on their work.  Steve Carter, of Bellcore, presented the
scope and charter of the system administration group, 1003.7, and
explained their use of an object-oriented paradigm.  Jim Oldroyd, of
the Instruction Set, followed this by presenting the work of 1003.7's
interoperability subgroup.

Kester Fong, of General Motors, gave an overview of the FTAM group.
He left us with the impression that there wasn't much room for
collaboration, but we'll surely need to review the relationship
between the file-system's security semantics and those of FTAM.

Jason Zions, of HP, gave one of the most interesting and aggressive
presentations of the day, on the work of the Transparent File Access
Group, which included a preliminary list of issues that 1003.8 feels
need to be reviewed.

Finally, David Rogers, of ICL (Britain), gave a presentation on the
European security criteria.  He predicted harmonization by June, 1990
of the work of Britain, France, Germany, and Holland.  The European
criteria will define separate levels of functionality and assurance.
There will be ten classes of functionality.  The first five are
hierarchical and are similar to the U.S. Orange-Book criteria; the
remaining five address particular security needs, such as integrity,
availability, and networks.  There are seven classes of assurance.  A
product evaluated under these criteria is likely to receive a rating
from the first five functional classes, one or more of the next five
functional classes, and an assurance rating.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 7 -

4.7  Final Comments

With the short plenary session, the availability of the draft document
in electronic form, and the presence of many lap-top systems to work
on, this meeting was one of our most productive.  The group seems to
have picked up enthusiasm from the knowledge that our work is coming
together and the end is in sight.

June, 1990 Standards Update                      IEEE 1003.6: Security

Volume-Number: Volume 20, Number 55