Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.6 Security Extensions
Message-ID: <383@longway.TIC.COM>
Date: 31 Aug 89 19:57:52 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 290
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
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 (anama...@lll-lcc.llnl.gov) 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 (steina...@ecf.ncsl.nist.gov), 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
|