Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.6: Security Extensions Message-ID: <467@longway.TIC.COM> Date: 8 Dec 89 18:24:15 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 209 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jeffrey S. Haemer 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 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