jsh@usenix.org (Jeffrey S. Haemer) (10/21/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.6: Security Extensions Update
Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> reports on the July
10-14, 1989 meeting, in San Jose, California:
P1003.6 (security) is split into four main groups: privileges,
mandatory access control (MAC), audit, and discretionary access
control (DAC). In addition, there is a definitions group, whose
charter is to define terms and to insure that definitions used by
1003.6 do not clash with definitions in other 1003 groups.
1. DEFINITIONS
The definitions group reviewed all definitions new to draft two.
The majority were from the audit group and were approved.
Amusingly, the lone exception was the definition of "audit",
which included an interpretation of an audit record; the
definition group considered this to be outside the audit group's
goals.
The group also chose a global naming convention,
PREFIX_FUNCTIONNAME, where PREFIX represents the security
section/topic. Current prefixes are "priv_", "mac_", "aud_",
and "acl_" (DAC). The same prefix rule extends to data
structures (e.g. "priv_t").
2. MAC
Several issues were resolved.
o+ A 'write up' standard will be neither restricted nor
guaranteed.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.6: Security Extensions
- 2 -
o+ The 'upgrade directories' function was dropped, since a
'write up' without a read does not guarantee success.
o+ Change file label/level and change process label operations
will be accepted for privileged processes
o+ The MAC_PRESENT variable will be added to the sysconf, to
indicate that a MAC mechanism is installed in the system.
MAC_CONTROLLED and MAC_ALWAYS were also proposed.
MAC_CONTROLLED would return the value of a file controlled
by a MAC mechanism, and MAC_ALWAYS would indicate that all
objects on the system contain associated MAC information.
o+ A set of six privileges were defined: P_upgrade,
P_covertchannel, P_MAC_READ, P_MAC_WRITE, P_LABEL_OBJ,
P_LABEL_SUBJ. The last two might be folded under
READ/WRITE privileges, however these two are the most
sensitive of all.
The next meeting will see discussions of SUN's multiple-level
directories, the recalculation function, and information labels.
The group will also review the .6 draft, the MAC common
description language interface, and 1003.1/.1a.
3. PRIVILEGES
The privilege group has defined interfaces for file privileges.
For example, priv_fstate_t() will return whether privilege for
the file is required, allowed, or forbidden. A process's
privilege can be permitted, effective, or inheritable.
Also, there is now a list of needed privileges, including
PRIV_SETUID and PRIV_SETGID (set the uid and gid of a file or
process), PRIV_FOWNER (change the owner uid of a file),
PRIV_ADMIN (do administrative operations like unlinking a file),
PRIV_RESOURCE (set the sticky bit or be able to use memory),
DAC_READ/WRITE (override access search or read and access write)
The process-privilege interface is still an open issue, and will
be discussed in October. These three suggestions are on the
table:
1. A function pair. priv_set_priv(id,attr,value) and valuet
priv_get_priv(id,attr). (Something of type "valuet" can
take on the values "required", "allowed", or "forbidden".)
September 1989 Standards Update IEEE 1003.6: Security Extensions
- 3 -
2. An interface to set or unset multiple privileges at a
time.
3. A requirement that the operating system re-calculate
privileges for each process every time that process
manipulates an object.
Next meeting, the privilege group will focus on developing
functional interface descriptions in both English and in Common
Descriptive Language (CDL).
4. DAC
The DAC group decided to describe interfaces using a procedural
interface. They defined the minimum set of functions required
for access control lists (ACLs) -- open, close, write, sort,
create_entry, get_entry, dup_entry, delete_entry, set_key,
get_key, and add/delete permission -- and the minimum set of
commands -- getacl and setacl. They also defined the needed
privileges and passed their list to the privilege group. The
October meeting will focus on polishing the current draft and
addressing default ACL interfaces.
5. AUDIT
The group discussed portability, especially data portability.
Should only privileged processes write to audit logs? (The
consensus is, "Yes.") And how much should the record format be
standardized?
The October meeting will see a draft review, plus discussions on
event identification, classes, style and data representation,
and token grammar.
6. NEW GROUP: NETWORK/SYSTEM ADMINISTRATION
Because interconnectivity is at the heart of many security and
administration issues, "interconnectivity" between P1003.6,
P1003.7 (system administration), and P1003.8 (networking) had to
improve. A joint, evening meeting of the three groups set this
in motion, and five members of 1003.6 have signed up to review
drafts from the other two groups. They intend to begin working
on this area formally in October.
September 1989 Standards Update IEEE 1003.6: Security Extensions
Volume-Number: Volume 17, Number 42bbadger@X102C.harris-atd.com (10/25/89)
From: <bbadger@X102C.harris-atd.com> In article <412@longway.TIC.COM> you write: [with sections liberally elided...] [I've removed more from the quoted message. -mod] >From: Jeffrey S. Haemer <jsh@usenix.org> >... >IEEE 1003.6: Security Extensions Update >Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> reports on the July >10-14, 1989 meeting, in San Jose, California: > 3. PRIVILEGES > > The privilege group has defined interfaces for file privileges. > For example, priv_fstate_t() will return whether privilege for > the file is required, allowed, or forbidden. A process's > privilege can be permitted, effective, or inheritable. Could you explain the meanings of the priv_fstate_t() values? I'm guessing: process: permitted -- process may turn on this privilege effective -- process has turned on this privilege inheritable -- upon an exec, privilege remains in effect file (effect when exec occurs): required -- ORs with the permitted and effective allowed -- ORs with the permitted forbidden -- removes inheritable privileges (and (NOT forb)) p->permitted = (p->inheritable | ip->required | ip->allowed) & ~ip->forbidden p->effective = ((p_effective & p->inheritable) | ip->required) & ~ip->forbidden Is this the intent? -- ----- - - - - - - - ---- Bernard A. Badger Jr. 407/984-6385 |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively. Volume-Number: Volume 17, Number 48
jsh@usenix.org (Jeffrey S. Haemer) (12/09/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.6: Security Extensions Update
Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> reports on the October
16-20, 1989 meeting in Brussels, Belgium:
The security working group worked the full week, discussing the draft.
The meeting's primary goal was to approve the current draft for
distribution to the international working groups. It was presented, at
the EEC, to new members of the group from the European countries, and
every member introduced himself/herself the first day of the meeting.
Once introductions were out of the way, we dealt with the major topics
that follow.
TRUSIX
A representative from TRUSIX, Charles Testa, gave the usual progress
report on TRUSIX. [Editor's note -- TRUSIX is an organization
sponsored by the National computer security center (NCSC), developing
a secure UNIX model. The participants are a number of vendors
developing secure UNIX implementations.] Their modeling subcommittee
has nearly completed a formal model describing the UNIX file system.
They have accepted the "Ina Jo" model to describe Trusted UNIX System
Interfaces. This model revolves around a MAC-read criterion, MAC-
writes and a DAC constraint, and consists of simple security
properties, confinement properties, and discretionary security
properties representative of the Bell-LaPadula model.
The TRUSIX ACL Rationale and Working Example Document has been
approved by the NCSC and is being reviewed for publication under NCSC
security publications.
One topic of interest to all security readers is prevention and/or
detection of covert channels. TRUSIX is planning to include this
under the Audit Rationale Document, which will include examples of
typical covert channels and their implications. Issues such as
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.6: Security Extensions
- 2 -
bandwidth evaluation will be addressed by a separate white paper.
POSIX Conformance Testing
A representative from 1003.3,the POSIX Conformance Testing group,
presented 1003.3's goal -- to establish a series of specifications for
testing the different POSIX standards. Although they have written the
pseudo-code to test the conformance of a system to 1003.1, they feel
they lack the staff and expertise to produce such tests for all the
1003 groups. Given this, their current plan is to draw upon each
group for expertise and background knowledge of the subject at hand,
and join those skills with their testing skills to produce a test bed
for each 1003 standard.
Their ultimate goal is to allow testing of all elements of an open
system for POSIX conformance by defining common test methods, which
can then be implemented by private industries as test suites. They
explained how to list the assertions, how to classify them, and what
information they will need to produce a test method for 1003.6.
One factor mentioned was that the description has to address a single
unit of behavior expected of a conformant system at a time. This
implies dissecting interfaces into separate groups of assertions and
generating assertions for both semantic and syntactic descriptions.
Discretionary Access Control (DAC)
The group focused on polishing and adding information to the draft.
It was suggested the standard shouldn't define the behavior of 'chmod'
when old programs are being executed with the DAC mechanism.
It was noted that the current proposed Access Control List (ACL) might
not be fully compatible with the current behavior of a 'chmod' call.
With the current, old-style behavior, when 'chmod' is used to change
owner, group and/or other permissions, the changed permissions
represent the access modes of the file. In the current proposal for
ACL, a 'chmod' will provide the old behavior for the "owner" and
"other" fields, but the "group" field permissions as set by 'chmod'
and shown by 'stat', wouldn't represent the actual access permissions
of the group associated with that file; instead, it's a summary of all
access permissions included under the ACL list for group entries. In
other words, it would represent the maximum permissions allowed to the
group entries included in the ACL list.
Some participants argued that 'chmod' should be replaced by other
system calls in a system conforming to 1003.6. In other words, if
your system were to conform to 1003.6 the behavior of chmod would be
December 1989 Standards Update IEEE 1003.6: Security Extensions
- 3 -
unspecified and unpredictable.
I disagree. Although defining the behavior of 'chmod' might restrict
some implementations of ACLs, having a well-defined chmod behavior
will provide backward compatibility and ease porting old programs to
1003.6-conformant systems. Otherwise old programs will have to be
ported to platforms with system-dependent representations of 'chmod'
and 'stat' information.
It was also proposed that the ACL list should allow entry types like
timestamping. This would allow a policy that is more restrictive than
the DOD, orange-book policy to provide more granularity of file
access.
Mandatory Access Control (MAC)
Kevin Murphy, of British Telecom, presented his views on electronic-
mail-label usage and proposed that such a mechanism should be used as
part of the standard. The electronic mail security labels consist of
a generic format that includes four major components: security policy
id, security classification, privacy mask, and security categories.
This approach to labels is implemented on X.400 security services.
One clear advantage of using such a format for labels is that it
maximizes the potential synergy between operating-system and
electronic-mail labels.
Chris Hughes from ICL presented British views on MAC information
labels. Its main characteristics are these: object creation
initializes the label, the label is implementation-defined and changed
by the owner, and the label is not used for access control. Chris
proposed that the standard should provide a get/set mechanism for the
object information label, and a way to merge and translate information
labels, but should not standardize the labels' contents.
Information labels are useful because they provide added information
on particular objects. We concluded that information labels should be
in the scope of MAC as part of the standard, and requested that MITRE
provide a presentation on information label use at the next meeting.
Privileges
The whole group heard a presentation of the internal draft of the
privileges document. We decided that the wording had problems. The
draft interface description is too obscure and needs a simpler
description of privilege interfaces, before it can be included in the
1003.6 draft document.
December 1989 Standards Update IEEE 1003.6: Security Extensions
- 4 -
Although the group argued considerably about the wording, they seemed
to agree on the concepts. The main points are that privilege is
associated with a process and privilege attributes can be attached to
files.
I do not think I should burden the reader with the brainstorming ideas
of the privilege group until a firmer position is taken at the next
meeting. One thing I can say is that the process-privilege concepts
described in my last report (permitted, inheritable and effective),
still stand, and a file still has three types of privilege attributes.
Audit
Kevin Brady from AT&T and Doug Steves from IBM presented a combined
proposal, produced by them and Henry Hall from DEC, on how to define
audit interfaces for 1003.6. Their proposal was meant to contest the
current audit stand, lead by Olin Sibert from Oxford Systems.
The current audit definition is based on the token concept and on a
pure procedural interface. In the procedural interface all data
manipulation of the audit record is performed by function calls, with
data passed explicitly through function parameters. Although this
sounds attractive and clear, in practice it requires many function
calls.
Another major point of controversy was the audit trail format. In
Olin's proposal, conversion cost is minimal because writes and reads
require an explicit specification of the format wanted. In Kevin,
Doug and Henry's proposal the conversion function is set to one of
three conventional formats: little endian, big endian, or XDR. In
other words, the information is stored in machine-dependent format
while Olin's chooses a uniform format for all information stored.
One last contested feature was the ability to rewind audit trail
information when viewing it. Kevin, Doug and Henry's proposal does
not allow a rewind, since information is manipulated at the data-
structure level.
Because of the heated discussion of procedural versus data-structure
interfaces for POSIX, both proposals will be formally written out,
removed from the draft, and presented in the next meeting for a final
vote.
December 1989 Standards Update IEEE 1003.6: Security Extensions
Volume-Number: Volume 17, Number 94