Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.29/text0065.txt

Text File | 1992-12-26 | 5.5 KB | 136 lines

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor


POSIX.6 - Security Extensions


Charisse Castignoli <[e-mail]> reports on the July
13-17, 1992 meeting in Chicago, IL :

The POSIX.6 group continued to work on new project authorization
requests (PARs).  Two PARs have been submitted to the Project
Management Committee (PMC). They are:

   - A Secure General Terminal Interface (GTI)

   - Identification and Authentication

Other PARs, such as a portable interchange format, have not been
submitted to the PMC due to the lack of resources to work on them.

In response to requests by individuals to assess whether or not
POSIX.6 could go out as a trial use standard, Mike Ressler suggested
we carefully analyze this approach.  We need to go back and look at
what the Trial Use definition from the IEEE is, and try to determine
what the right approach is for POSIX in general, NOT just POSIX.6.

Monday:

The POSIX.6 ballot resolution committee continued to slog through the
comments and objections.  We work individually on our laptops, and
then send a merged document back to Bellcore.  Mike Ressler and his
horde of great editors then patch together our individual sections and
email out the updated sections.

Of course, you can imagine what happens when a laptop breaks down. The
person depending upon it instantly becomes an order of magnitude less
productive.  This week's session began with the power supply failure
of one of the laptops.  No problem, says customer service, we'll ship
you a new power supply overnight and have you up an running in no
time.  We should have started taking odds on whether the power supply
or the end of the meeting would arrive first!

Despite our hardware limitations, the committee still struggled on..

Tuesday:

We spoke for a long time about multi-level directories, and whether or
not they should be in the standard.  Multilevel directories, are a
technique used to solve the problem of public directories (such as
/tmp and /usr/spool). In a trusted system with more than one
sensitivity level, a process at SECRET can not view files created by
processes at TOP SECRET.  To solve this problem, the idea of creating
non-visible subdirectories, one for each level, was hatched.
Processes without a privilege will only see files in their
subdirectory. To this process, the pathname would look like
"/tmp/mysecretfile". But to a process with the multilevel privilege
the pathname would look like "/tmp/SECRET/mysecretfile".

Kevin Brady pointed out that there were very few existing applications
that actually needed to view the resulting true multilevel directory.
Most applications just want to create a file and are unaware of
whether the underlying directory is multilevel or not.

For example, in current UNIX trusted systems, vi writes file to /tmp.
vi is unaware that /tmp is a multilevel directory, however expreserve,
the program that reclaims vi drafts from /tmp, is mulit-level aware.

Our power supply didn't arrive today....

Wednesday:

One of the most controversial ballot resolution issues we face is that
we do not have a consistent storage and allocation model for the data
structures that the POSIX.6 interfaces manipulate.  Some functions,
such as the Mandatory Access Control (MAC) and Information Labels (IL)
interfaces, lend themselves to persistent opaque data types.  Others,
such as the Access Control List (ACL) interfaces, require data types
that are non-persistent.

It is amazing that almost two years after this issue was raised, after
many hours of thought and great debates over countless beers, we reach
the final hours of ballot resolution and still have not reached
consensus.  The resolution of the day is:

   - MAC, IL, are going to be persistent opaque,

   - Audit, Discretionary Access Control (DAC) and PRIV are
     going to be non-persistent opaque

Still no power supply and it's the shippers fault according to
customer service.

Thursday:

The next controversial issue that was raised has its origins even
further back in the history of POSIX.6.  The discussions go all the
way back to /usr/group meetings!  This is the ACL feature called the
mask.  The mask was introduced as a mechanism to:

   - map UNIX mode bits into an ACL,

   - map chmod() calls to manipulations of an ACL

   - provide backwards compatibility with the current uses of the mode
     word.

In order to achieve maximum compatibility, (but not 100%), the ACL
algorithm became incredibly complex as ACL entries became subject to
restrictions and manipulations incurred by the mask.  The algorithm
became esoteric, to the point where this reviewer believes that no one
without a PhD in computer security will be able to understand it.

In order to simplify the algorithm, the mask has been deleted.  Now,
mode bits are converted to ACL entries, and chmod() only effects the
UNIX mode bits.  A POSIX configuration option allows the application
to select whether or not to receive an error when chmod() is executed
on a file the has an ACL on it.

No power supply - but it will be there tomorrow for sure for sure.

Friday:

Most groups are 80-95% complete on their pass through the objections
and comments.  ACLs, who had a few extra to begin with, still have the
furthest to go.  The committee would like to go out for re-ballot or
re-distribution at the end of the Utrecht meeting.

UPS finally delivers Roland's new power supply just in time to pack up
his laptop, and get absolutely no use out of it whatsoever.

Volume-Number: Volume 29, Number 67