std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (09/01/89)
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 (anamaria@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 (steinauer@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