pc@hillside.co.uk (Peter Collinson) (04/13/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
1003.6: Security Extensions
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
April 12, 1991
Ana Maria de Alvare <anamaria@sgi.com> reports on the
January 7-11, 1991 meeting in New Orleans, LA:
Overview
The P1003.6 group met for the entire week. Our main task was
preparing draft 8 for mock ballot. We also planned for P1003.6 test
assertions and discussed file locking, manipulating or duplicating the
information in opaque data objects, and allowing ps to show privileges
and MAC labels of processes.
We also heard two proposals at the meeting, one on Privileges and one
on Discretionary Access Control, which I discuss in the relevant
subgroup sections, below.
Mock Ballot
P1003.6 plans to go to mock ballot after our April meeting. We will
review comments at the July meeting, and try to ballot the document
soon afterwards. The October meeting will be used for ballot
resolution and clean-up.
To prepare for mock ballot, the working group submitted written
comments on the current draft, and subgroups spent the week addressing
them. Commenters included Chris Hughes (ICL), Roland Clouse (Unisys),
Dan Ujihara (SUN), and me (SGI).
Test Assertion Plans
The group decided to create a separate test-assertions document that
parallels the current document. Each subgroup will be responsible for
its own test assertions, and will ensure that the assertions document
and the main document remain consistent. (I.e., any updates to the
P1003.6 document will trigger changes to the assertions document.)
Dave Rogers (Data Logic) and I are co-chairing this effort. If you
are interested in helping to write test assertions, please let us know.
Opaque Security Data Object Duplication
Duplicating the information in opaque security data objects - ACLs,
labels, and privileges - presents three distinct kinds of problems:
1. duplicating the information within a process,
2. passing the information between processes in a single
system, and
3. exporting the information out of a system.
Copying the information within a process is simple. What's hard is
copying it out of the process's context - for example, for backups.
We decided that such exporting will require passing out both object
addresses and sizes, as well as data characteristics, such as binary,
text, or function.
Privileges
John Griffith (HP/Apollo) presented a new privileges proposal that
simplified determining whether a process has, lacks, or inherits a
privilege.
In draft 8, a process could only inherit privilege if the ``allowed''
file-privilege attribute was set: inheritance, through the inheritable
group, depended on restrictions provided by the ``allowed'' file
privilege attribute.
The subgroup agreed that this needed simplifying. The newly agreed-on
substitute is that a privilege can be inheritable if it exists in the
inheritable group or if the file's ``forced'' privilege attribute is
on. In other words, after an exec occurs, a privilege that is on in
the inheritable privilege group can turn itself on in the permitted
privilege group.
The subgroup spent much of the remaining time editing its part of the
document. Two issues I hope will be resolved next meeting are:
1. accommodating privileged shell scripts in the current
proposal, and
2. determining how to store privilege information for
later use.
Discretionary Access Control
The new DAC proposal consisted of two documents representing a
collaborative effort by Paul Karger (OSF), Rand Hoven (HP/APOLLO), and
Jon Spencer (Data General). It tried to simplify the way default ACLs
and MASK OBJs work, and it removed any requirement for MASK OBJ
entries when no additional ACL entries existed. In the end, we
decided to retain the old scheme but will try to shore up areas that
the new proposal pointed out were particularly weak. The proposal's
sponsors agreed to this, providing the new draft offers a satisfactory
alternative simplification.
The subgroup also attacked the opaque object issue described earlier,
defining an interface to interconvert DAC opaque objects and text
strings, and a relocatable ACL format that can be stored in an audit
record.
The DAC subgroup will pass their draft to the full group after the
next meeting.
Mandatory Access Control
The MAC subgroup discussed the written comments to their section and
feel they will be ready for ballot after the next meeting.
Two major issues arose:
1. whether our document should address special (block and
character device) files, and
2. whether we needed a dup()-like function to copy
internal formats.
The subgroup decided the current version of P1003.6 shouldn't address
terminals or other special files, but the second issue will be passed
on to the entire group.
Audit
The Audit subgroup discussed all the written comments and will only
need one more meeting to be ready for ballot. Their work, including
mandatory record types, will be based on X/Open's. They will not
address Portable Data Record Format, and optional record types will be
implementation-defined.
Clearly, audit functions will need both pointers to objects and their
sizes to operate on MAC, DAC, and Privilege opaque data. Because of
this, I predict all three subgroups will have to provide interfaces to
provide the information.
Liaison .6/.7/.8
The liaison group met again to discuss areas of compatibility and
overlap between our respective documents. (The October P1003.6 snitch
report sketches our ongoing agenda.) We identified areas that P1003.6
(Security), P1003.7 (System Administration), and P1003.8 (TFA) already
handle, areas we might handle, and areas that are falling through the
cracks. After we finish identifying areas of concern, we may write
PARs for anything we cannot farm out to existing groups. In April, we
will discuss how to report our findings back to the three groups.
Volume-Number: Volume 23, Number 31