Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1989.08

Text File | 1989-09-07 | 31.6 KB | 804 lines

echo 89.08.overview
cat >89.08.overview <<'shar.89.08.overview.13057'
From news  Wed Aug 16 12:36:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA13000; Wed, 16 Aug 89 12:36:24 -0400
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Minneapolis, Overview
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Jeffrey S. Haemer <[e-mail]>
Date: 16 Aug 89 05:01:31 GMT
Apparently-To: std-unix-archive

[ There are two sets of USENIX Standards Watchdog reports
that have not yet been posted.  This article begins the set
from the April 1989 meeting in Minneapolis.  The ones from
the July 1989 meeting in San Jose will follow later.  -mod ]

From: Jeffrey S. Haemer <[e-mail]>


>From April to July of this year there was no report editor for
the USENIX watchdog committee reports.  Shane McCarron, who did a
spectacular job editing the first several sets of reports, had
been called away to bigger (though not better :-) things.  For months,
volunteers' reports on various aspects of the April meeting lay
on an electronic shelf.

In July, John Quarterman somehow got me to volunteer to do report
editing.  Since then, I've worked both to clear out the backlog
and to persuade volunteers to generate new reports, despite the
fact that their old ones haven't even been posted yet.

To get things rolling again, I've chosen to sidestep prior
practice, and just provide edited versions of the reports I have.
If you haven't been following these reports, the difference is
that Shane fused the watchdog reports, his observations, and his
opinions into strong, occasionally controversial editorials.  In
these postings, my biases will leak through, but due to the amount
of catching-up I need to do, I've mostly edited, not
editorialized.

Here's what this means.  Each edited report is tagged with the
name and e-mail address of the original report author.  If you
want elaboration on a statement of fact, please contact the
watchdog; if you think the facts are presented in a light
that lead the reader to the wrong conclusion, your argument's
probably with me.

Jeffrey S. Haemer
Report Editor
[e-mail]


Volume-Number: Volume 17, Number 2

shar.89.08.overview.13057
echo 89.08.x3j11
cat >89.08.x3j11 <<'shar.89.08.x3j11.13057'
From news  Wed Aug 23 12:48:48 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA18246; Wed, 23 Aug 89 12:48:48 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, X3J11 C Language
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 23 Aug 89 16:47:30 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

ANSI X3J11 C Language Update

Doug Gwyn ([e-mail]) reports:

There's not much new on the X3J11 (ANSI C) front.

As of about a week ago [i.e, mid-May, 1989 - jsh], X3 had not yet
finished the reballoting caused by having to respond to a previously
lost, public comment letter from Russell Hansberry. X3J11 discussed
these comments with Hansberry at the Seattle meeting, voted on some
resulting proposals, and, in summary, reaffirmed previous resolutions
of and decisions about all his issues.  In all, no changes were made
to the December 1988 draft proposed standard and rationale documents.
An official response was sent to Hansberry, who had 15 working days to
respond to X3, after which X3 would again ballot on whether or not to
send the proposed C standard to ANSI for ratification.  Hansberry
replied, requesting a full formal review process.  Since this was
previously approved, we expect the same outcome for the reballot, but
the people involved in the appeals process are not the same as the
ones with technical expertise who drew up the standard, so anything
could happen.  Certainly there will, at least, be a substantial delay
in obtaining final approval of the submitted standard as an ANSI
standard.

ISO WG14 met concurrently in Seattle.  A Danish proposal for an
alternative to trigraphs was defeated by both X3J11 and WG14; although
one might hope that we've heard the last about this, the delay on the
ANSI side might permit more hassle from the Danes. WG14 also agreed to
submit the same proposed standard as ANSI's for ISO approval, with the
understanding that British concerns about excessive instances of
"undefined" behavior would be addressed early in the X3J11
"interpretations" phase. Specifically, the British would like all such
instances clearly identified.  X3J11 is working with them to prepare
an "information bulletin", which would clarify the standard without
forcing a revision of the proposed standard itself.

X3J11 work for the foreseeable future will concentrate on answering

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -            ANSI X3J11 C Language

questions about the standard and providing rulings on interpretations.

No new instances of X3.159/1003.1 conflict have arisen, to my
knowledge, since the "great `environ' problem".  There have been
several varying interpretations of how vendors should define __STDC__
(if at all) in an "extended" implementation of X3.159, such as most
POSIX vendors will be doing for reasons of backward compatibility.
X3J11 certainly intended all positive integral values of __STDC__ to
be reserved for strictly standard- conforming implementations of C;
there is some disagreement whether non-positive values should be used
by vendors to indicate "ANSI C except with extensions".  Unfortunately
there is no way to constrain non-conforming implementations via
wording in the standard.

A proposal that X3J11 undertake standardization of C++ was rejected;
although there was a consensus that C++ was ready for a standards
effort to begin, it was not felt that C++ should be undertaken by
X3J11 itself, for a variety of reasons.

Rex Jaeschke has formed a "Numerical C Extension Group", which has
begun work on identifying extensions needed for C to fully serve the
numerical computing community.  This is not yet officially under X3
auspices, but it could become so.

The X3J11 meeting slated for September, 1989 in Salt Lake City was
canceled due to the approval delay; the next scheduled meeting is in
New York City on March 5-6, 1990.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee

shar.89.08.x3j11.13057
echo 89.08.1003.0
cat >89.08.1003.0 <<'shar.89.08.1003.0.13057'
From news  Thu Aug 31 19:19:39 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA04695; Thu, 31 Aug 89 19:19:39 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0 POSIX Guide
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 20:03:12 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.0: POSIX guide Update

An anonymous correspondent reports of the April, 1989 meeting:

The April session of 1003.0 was fruitful.  The most significant
accomplishment was the proposal and development of definitions the
committee feels it needs to describe an open systems environment
properly and adequately.  Five definitions were developed:

   o+ open system environment

   o+ application environment

   o+ application environment description

   o+ application environment profile

   o+ POSIX open system environment

Group consensus was that the first four would be submitted to the JTC1
Application Portability Study Group as a draft proposal for its work.
The committee added the caveat that these were draft definitions,
subject to change.  A key clarification by these definitions was the
distinction between an application profile and an open system
environment: a profile is a subset of the environment.

The guide document, being developed by 1003.0, is nearly mature.
Significant strides were made in the architecture section, which
focuses on the operating system interface, languages, and network
services.  In the following months, 1003.0 will turn its attention to
database management, data interchange, and graphics.  The user
interface section will be closely coupled to the work of the newly
formed, IEEE 1201.1 (Xwindows) working group.  Similarly, the the
transaction processing section will track the on-line transaction
processing (OLTP) group (1003.11).

There is some worry about the length of the guide -- currently 135

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -         IEEE 1003.0: POSIX guide

pages and growing.  If the document becomes unwieldy, some attention
will be turned to scaling it down.

The committee also created an Internationalization study group, to cut
across groups and help increase inter-group coordination in this area.
The study group intends to become a full working group in Brussels,
this October.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 16

shar.89.08.1003.0.13057
echo 89.08.1003.1
cat >89.08.1003.1 <<'shar.89.08.1003.1.13057'
From news  Thu Aug 31 18:54:54 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29641; Thu, 31 Aug 89 18:54:54 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.1 System services interface
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 20:01:09 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.1: System services interface Update

Shane McCarron <[e-mail]> reports of the April, 1989 meeting:

"After thinking about it, I realized that 1003.1 did actually do some
stuff this quarter." [April -ed]

1003.1 is preparing two supplements, A and B, to 1003.1-88.

At the 1003.1 meeting in Minneapolis, the group reviewed draft 0.1 of
1003.1, supplement A.  This supplement contains only clarifications
and editorial comments, and will be balloted in the Summer.  It will
be provided to the ISO as the United States' comments on the
International Standard IS9945, which is the same as 1003.1-1988.  Its
goal is to insure that the ISO standard and the the IEEE standard
(with supplement) are functionally identical.

Supplement B, to be balloted later, contains substantive changes: new
facilities absent in IEEE Std 1003.1-1988.  Some were missing from
1003.1-88 because they weren't completely specified in time to be
included in the first release of the standard.  Others are being
introduced due to requests from other standards committees or the user
community.  For example, the ISO working group responsible for POSIX
has requested a new archive format.  It argues both that the archive
formats in the first standard are insufficient for the future needs of
POSIX systems and that a dual solution is unacceptable.  The new
format uses ANSI standard labeling, but extends it to permit POSIX
filenames, security information, etc....  Supplement B also includes
symbolic links, truncate(), ftruncate(), putenv(), clearenv(),
getpass(), seekdir(), telldir(), chroot(), fchmod(), fchown(), and
fsync().

Supplement B will also contain additional clarifications and edits to
the base standard.  The ISO will probably designate this supplement an
addendum to IS 9945.  All this maneuvering insures that the different
standards stay in sync, and prevents large delays in getting the ISO

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    -IE2EE-1003.1: System services interface

standard approved.

Although 1003.1-88 is now official, the 1003.1 committee's work will
continue for some time yet.  As other POSIX standards gel, their
committees uncover requirements for additional functionality or
semantics in the base standard, to support their work.  As these
committees point out such cavities in the standard, P1003.1 works to
fill them.  Everyone's hope is that no root canals will be necessary.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 15

shar.89.08.1003.1.13057
echo 89.08.1003.1.a
cat >89.08.1003.1.a <<'shar.89.08.1003.1.a.13057'
From news  Fri Sep  1 13:13:36 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA11124; Fri, 1 Sep 89 13:13:36 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, 1003.1 System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Sep 89 01:18:10 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] writes:
>....  Supplement B also includes symbolic links, truncate(), ftruncate(),
>putenv(), clearenv(), getpass(), seekdir(), telldir(), chroot(), fchmod(),
>fchown(), and fsync().

We deliberately left seekdir() and telldir() out of IEEE Std 1003.1,
because they cannot be reliably implemented in all reasonable UNIX-based
environments.  I wish people would quite trying to second-guess the
original work.

Volume-Number: Volume 17, Number 17

shar.89.08.1003.1.a.13057
echo 89.08.1003.5
cat >89.08.1003.5 <<'shar.89.08.1003.5.13057'
From news  Wed Aug 23 15:37:00 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA11090; Wed, 23 Aug 89 15:37:00 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.5 Ada Language
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 23 Aug 89 19:16:31 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.5 Ada Language Update

Ted Baker ([e-mail]) reports of the April 1989 meeting:

The Minneapolis meeting started off poorly.  The chairman, co-
chairman, and technical editor were absent, though each for good
reasons.  ("Co-chairman" is POSIX for vice-chairman.) Only one of the
members present had received a copy of the latest draft (2.0).  Many
of the changes agreed upon at the last meeting (Fort Lauderdale) were
not yet reflected in this draft.  There was no agenda.

Despite these handicaps, the group made considerable progress. Steve
Deller acted as chair, working up an agenda and holding the group
fairly closely to it.  (Indeed, Steve Deller has now become an
official co-chair, but is still doing a good job.)

By the second day copies of Draft 2.0 had been made.  This draft was
reviewed completely, and several changes were approved.  The hottest
issue was how signals would be mapped to Ada task entries.  Several
semantic gaps in the P1003.1 C-language binding were discovered, and
passed on to the P1003.1 working group.

Most major semantic issues were, at this point, resolved.

  1.  Each Ada program consists of a single POSIX process, or at least
      appears to be so through the POSIX/Ada interface.

  2.  POSIX signals are handled by Ada tasks via the same mechanism as
      hardware interrupts, as logical entry calls.

  3.  POSIX character and string types are distinct from the standard
      Ada character and string types.

  4.  The C-binding's "errno" values are translated into distinct Ada
      exceptions.

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -         IEEE 1003.5 Ada Language

  5.  The Ada-binding need not follow the organizational and naming
      conventions of the C-binding, especially where they violate
      principles of data abstraction.

What remains is filling in a lot of details, including most of the
text of the document, and making it stylistically consistent.

Group members volunteered to edit the agreed-upon changes into the
draft document, while filling in missing text.  This work was to be
completed before May 10-12, at which time a subset of the working
group would meet in Bedford Mass.  for a "writing party".  The goal of
this party would be to catch up, completing all missing portions of
the draft, so that it could be submitted for mock ballot before the
July P1003 meeting.  There was some question whether this goal would
be met.  (The mock ballot date was missed, so it appears 1003.5 won't
have an official Ada language binding that corresponds to 1003.1 by
end-of-year 1989.)

There were also coordination meetings (BOFs) with the groups working
on language-independent specifications (P1003.1) and threads
(P1003.4).  The Ada group seemed generally pleased with progress on
the language-independent specification, and hopes that the draft Ada-
binding will provide some guidance to that activity.  The group is
less pleased with the tendency of other groups (e.g.  P1003.2 and
P1003.4) to aggravate the problem of C-dependencies in their draft
documents.

The Ada group is very interested in having the 1003.4 standard include
multi-threaded processes, but is very concerned that any such standard
be compatible with the semantics of Ada tasks. Some of the preliminary
proposals coming out of the threads working group do not seem to be
compatible with this goal.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee

shar.89.08.1003.5.13057
echo 89.08.1003.6
cat >89.08.1003.6 <<'shar.89.08.1003.6.13057'
From news  Thu Aug 31 18:54:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29565; Thu, 31 Aug 89 18:54:11 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.6 Security Extensions
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 19:57:52 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare ([e-mail]) reports of the April,
1989 meeting:

P1003.6 covered these global issues at the five-day Minneapolis
meeting:

  1.  Supplements to 1003.1 will address portability, data interchange
      format, and symbolic links. This means 1003.6 must also consider
      those areas.

  2.  1003.6 would like to define a system variable that tells what
      security policies are allowed on the system, and a function that
      returns which security-related attributes (e.g., MAC, ACL) are
      currently in operation.  Such changes would need to be made in
      collaboration with 1003.1.

  3.  Other pieces of 1003.1 and its supplements may conflict with
      security extensions.  A short-term subgroup was proposed to
      review these documents and propose additions or changes.  1003.6
      is looking for volunteers for this work.  [Ed.  -- If you have,
      or can imagine, the orange book and the ugly green book side-
      by-side on your bookshelf, now's the time you should work to
      insure that only their colors clash.  The chair of 1003.6 is
      Dennis Steinauer ([e-mail]), who, we believe,
      would be happy to hear from you if you're willing to help.]

  4.  Two members of the networking group (1003.8) joined 1003.6 for
      half a day to list and explain their areas of concern:
      transparent file access, authentication at mount time, setuid
      programs, file format, local id contents, and who does the
      audit.  These issues were scheduled to be re-visited at the San

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 - IEEE 1003.6: Security Extensions

      Jose meeting in July in a joint meeting of the two groups.

  5.  Charlie Testa gave a status report on TRUSIX.  The TRUSIX
      working group responded to Tom Parenty's paper, which summarized
      the TRUSIX efforts.  The members felt compelled to clarify
      certain sections that they believed misconstrued their real
      objective: the creation of a trusted UNIX operating system.
      This response is also published in the December, 1988, Data
      Security Letter Journal.

      There are serious conflicts and points of contention between
      POSIX and TRUSIX.  POSIX is worried that systems conforming to
      TRUSIX recommendations will get preferential treatment during
      product evaluation, that vendors who currently plan only Class
      B2 systems or below are excluded from TRUSIX, and that
      participants in TRUSIX share proprietary information.  TRUSIX
      takes the position that the marketplace should be the final
      judge.  TRUSIX will be POSIX compliant, and will make no attempt
      to force vendors to be both POSIX and TRUSIX compliant.  If
      customers force a de-facto standard of dual compliance for even
      non-DOD applications, so be it.

      TRUSIX's ACL proposal will be delivered to the IEEE at the July
      meeting.  The proposal is only a guide, and it will not be
      written in a formal specification language as a favor to the
      reader.

      TRUSIX's audit subgroup is trying to follow both POSIX and
      X/Open efforts in this area.  Their subgroup is focusing on
      pre-selection, in contrast to the 1003.6 focus on post-
      selection, and they will review a token-based scheme at their
      next meeting.

  6.  At the previous meeting, a common descriptive top-level
      specification language (DTLS) was proposed.  For the moment,
      this language will form an appendix to the draft, and will be
      used as an internal tool to let the group define unambiguous
      security interfaces.  Every subgroup of 1003.6 will provide
      descriptions of interfaces in both English and DTLS.  Steve
      Sutton will be the chair of the DTLS team, and will work in
      conjunction with the technical editor of the draft.

The Security Working group is split onto separate groups for audit,
discretionary access control (DAC), mandatory access control (MAC) and
privileges.  Each subgroup gave a summary report at the end of the
week and some were able to give a first-cut delivery schedule.  The
following is a short summary of each group's efforts.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 3 - IEEE 1003.6: Security Extensions

AUDIT:

The scope of the audit group encompasses audit definition, auditable
events, audit trail contents, and audit trail access and control.  The
group will also define a portable audit-trail data representation and
focus on post-processing event classes.

Audit records will include process identification, audit id, effective
user id, effective group id, media addresses, MAC labels and privilege
information.  In San Jose, the audit group will try to identify all
token types, define the audit id, propose some changes to the 'seek'
function, pursue event classes, and review and merge the DTLS
interface descriptions with the English sections.

DAC

The DAC group is almost done with its rationale section.  One question
this time around was how to pass access mechanisms based on DAC across
the network.  Currently, file ownership is the first access check; on
networked systems, this can lead to spoofing, particularly when root
tries to access files on other systems.

Another hot issue was access functions.  The consensus is that an
access function to an opaque DAC (i.e., one that prevents knowledge of
the structure) should replace the use of stat(),chmod(),stat() or
locking mechanisms for controlled file access.  The function will not
replace chmod(), stat() or permission bits; however it will define
operations that will allow applications to continue to work correctly
in the face of ACLs.

MAC

Issues addressed here come from the MAC requirement that all system
objects be labeled with security levels (e.g., CONFIDENTIAL, SECRET,
TOP-SECRET).  Two proposals were on the table -- one from Addamax, the
other from Olin Sibert -- but no strong consensus was reached.
Miscellaneous comments on the issues discussed:

  1.

         o+ Downgrading (of security levels)

         o+ How should it be done?

         o+ Must the old label dominate the new one?

         o+ Does downgrading need to be strictly controlled?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 4 - IEEE 1003.6: Security Extensions

         o+ What about upgrading?

  2.  Directory labels.
      mkdir should be allowed to label directories on creation, to
      permit portable, level-hierarchy-dependent applications.

  3.  File locking.
      The standard should address locks and may consider them as
      objects.

  4.  "Write-up" appends.
      Writing to a file at a level above you is known as "write-up".
      Processes can write to files that they can't read.  At first
      blush, this seems analogous to standard UNIX, which allows files
      with permissions --w--w--w-.  What MAC adds is the prohibition
      that the process even know if the write succeeds.  Because
      appending to such a file provides no way to assure that the
      write succeeded, requested file, the question of whether to
      allow such write-ups was raised and discussed.

  5.  Change of file level with open file connections.
      UNIX does not expect open connections to break.  (An exception
      is /dev/tty* on 4.3BSD, which can be checked for open connection
      breaks.) Since /dev/tty* are special files and 1003.1 doesn't
      address special files it was argued that 1003.6 need not either,
      but this issue will be discussed further in San Jose.

  6.  Open tranquillity.
      The tranquillity property states that a resource should not be
      in active use during changes to its attributes.  (See also issue
      #5 above.) It was stressed that POSIX should be defining states
      and mechanisms that are as safe as possible, obvious to
      implement, deterministic, and clear.  Only privileged processes
      should be able to change the MAC label of a file object.

  7.  Replication or Recalculation?
      Replication means copying current properties across from one
      label to another.  Recalculation means re-evaluating the
      situation, then assigning properties or attributes needed for
      each file to work as labeled.  The consensus was that
      recalculation is needed in the standard, but there was no
      consensus on how either recalculation replication should occur.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 5 - IEEE 1003.6: Security Extensions

  8.  Multilevel directories
      A "multilevel directory" is a directory with files at different
      levels (e.g., both TOP SECRET and CONFIDENTIAL).  Should a
      multilevel directory feature be available for general use?
      Should it be part of the standards?  If so, operations on
      multilevel directories would be restricted and functions to be
      able to create, check for existence, query for directory name
      would be required.  These directories would inherit their DAC
      from their parent.

      The directory that stores files the user can see at the current
      time, as determined by the label at request time, is the "access
      hidden directory".  An open question is whether access to such a
      directory should be controlled by process privilege or the
      pathname syntax.

  9.  Text Format
      Two proposals were put forward on text format, but only one was
      discussed because of time constraints.  Despite this, the group
      resolved that naming should be site-specific, but names should
      be unique and order-independent.  Furthermore, a label should be
      interpretable and unique.  One major problem was that the
      characters suggested for hidden directories were outside the
      constrained character set provided by 1003.1 -- [a-z][A-Z][0-9]
      and a very limited set of punctuation characters.

 10.  System High/Low?
      This government concept is used a lot in discussions of secure
      systems.  It was put on the agenda for the July, San Jose
      meeting.

 11.  Other Issues
      Should the standard assure a non-decreasing directory hierarchy?
      In other words, should subdirectories always have at least as
      high a level as the parent?  Should the standard define level
      ranges such as system high?  Should the standard define a
      process clearance range? (Clearance only defines how to specify
      an error return that the system is allowed to give.)

PRIVILEGES

The group reviewed interface functions defined at the previous
meeting, and agreed on all of them except 'exec()', which poses
unresolved problems about inheritance of privileges.  The group
expects to finish this in July.

Some of the functions defined so far are: is_effective(p),

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 6 - IEEE 1003.6: Security Extensions

make_effective(p), make_ineffective(p), is_inheritable(p),
make_inheritable(p), make_not_inheritable(p), is_permitted(p),
relinquish(p), make_effective_if_inherited(p), and
make_all_ineffective(p) -- all related to querying the process
privilege state.

Old goals were revised and new goals added, including: support for old
binaries, support for new binaries implementing true least privileges,
acquisition of effective privilege following exec(), prevention of
some programs from inheriting privileges, and unsetting of privileges
on exit from signal handlers.

Other issues included:

  1.  Privilege inheritance
      When is it needed?

  2.  Forbidden privilege
      Should a flag be available to forbid a process to gain a
      privilege?

  3.  Privilege System Variable
      Should the standard define a system variable to set privileges
      at installation time?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 14

shar.89.08.1003.6.13057
echo 89.08.list
cat >89.08.list <<'shar.89.08.list.13057'
From news  Fri Sep  1 15:43:49 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00931; Fri, 1 Sep 89 15:43:49 -0400
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Minneapolis report list
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Aug 89 20:08:49 GMT
Apparently-To: std-unix-archive

From: John S. Quarterman <[e-mail]>

Here is a list of the Standards Updates posted in August:

ANSI X3J11 C Language
IEEE 1003.0 POSIX guide
IEEE 1003.1 System services interface
IEEE 1003.5 Ada Language
IEEE 1003.6 Security Extensions
IEEE 1003.8 Networking

The IEEE 1003 reports were for the April 1989 meeting in Minneapolis.
The next ones will be for the July 1989 meeting in San Jose.

Volume-Number: Volume 17, Number 20

shar.89.08.list.13057
exit