Path: utzoo!attcan!uunet!usenix!std-unix From: jsh@usenix.org Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.6: Security Message-ID: <384@usenix.ORG> Date: 28 Jun 90 18:20:43 GMT Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Lines: 334 Approved: jsq@usenix (Moderator, John Quarterman) From: An Update on UNIX*-Related Standards Activities June, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.6: Security An anonymous source reports on the April 23-27 meeting in Salt Lake City, UT: Apologia This is my first and last review as a snitch. [ Editor: We thank you for doing it, and hope your circumstances change to allow you to file more. ] In it, you'll see no party line. My views will sometimes be controversial, and I hope they spark discussion and feedback. They represent neither the views of my company nor of its clients -- I'm submitting this anonymously so no one can misconstrue them as being my company's -- and they're certainly not meant to represent the consensus of the 1003.6 Working Group. I'll put my biases on the table. I'm a commercial user and commercial software provider, not a government user, government software provider, or UNIX vendor. To some degree, these biases have influenced the committee, since I've been active in the group since its inception and attended every 1003.6 meeting. With that perspective, let's begin. 1. Overview The 1003.6 Working Group is putting together a Department-of-Defense- inspired version of UNIX. Our efforts will help vendors sell systems to the U.S. Government and its contractors. All our interfaces will make it easier to evaluate conforming systems at one of the DoD's Trusted Computer Security Evaluation Criteria (TCSEC) levels. This is not inherently bad, but it does sell the commercial and international communities short. (More on this later.) The working group is considering four areas: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Least Privilege, and Audit. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. June, 1990 Standards Update IEEE 1003.6: Security - 2 - 1.1 Discretionary Access Control The DAC group's job is hard. They are devising an Access Control List (ACL) mechanism that must co-exist with the familiar user/group/other mechanism. ACLs are discretionary because the user, not the system, decides each object's access rights. The traditional user/group/other mechanism is also discretionary: file protections are specified by the user. ACLs extend this by allowing users to grant different access permissions to arbitrary lists of named users and groups. (In other words, the traditional mechanism is an ACL with exactly three entries.) Designing an ACL is easy; maintaining compatibility with chmod, stat, umask, and the file creation mask of creat isn't. 1.2 Mandatory Access Control MAC is another type of access control mechanism. All system objects get a security label and all system users have a security classification set by the system or the Security Administrator (Systems Administrator). Users have no control over this mechanism's application; objects created by a user of classification X automatically receive a security label of X. Only users with appropriate classifications can access or modify a system object. (As a useful, if inexact, analogy, think of the way UNIX automatically assigns file ownerships.) The TCSEC security criteria's popularity and widespread acceptance have given MAC another connotation -- that of a codification of the familiar, U.S.-government, hierarchical security classifications: Top Secret, Classified, and Unclassified. Government policy prohibits users of a lower classification from viewing work of a higher classification. Conversely, users at a high classification may not make their work available to users at a lower classification: one can neither ``read up'' nor ``write down.'' There are also compartments within each classification level, such as NATO, nuclear, DOE, or project X. Access requires the proper level and authorization for all compartments associated with the resource. The MAC group is defining interfaces for such a mandatory mechanism. It's not as confusing as it sounds, but outside of the DoD it is as useless as it sounds. (Prove me wrong. Show me how this DoD policy is useful in a commercial environment.) 1.3 Least Privilege The Least Privilege group is eliminating root. They're creating both a list of privileges to encompass all of root's special uses, (e.g., set-uid to a different user-id, create a directory, create a file system, override DAC protection) and a mechanism to inherit, assign, and enable those privileges. June, 1990 Standards Update IEEE 1003.6: Security - 3 - 1.4 Audit The Audit group is preparing a standard interface for a logging mechanism, a standard format for logging records, and a list of system calls and commands to log. 2. Standards At the ISO level, there will be no separate security standard. Our work will be merged with the 1003.1 (System Interface), 1003.2 (Commands and Utilities), and 1003.7 (System Administration) work in the ISO 9945-1, -2, and -3 standards. This means every conforming system will include security mechanisms. I like this. Do you? 3. Scope and motivation All 1003.6 members feel we are making POSIX secure, not merely helping sell systems to the U.S. government. Our work is important and necessary (except, of course, MAC), but I think our focus has been too narrow. We included mechanisms for the TCSEC criteria but stopped there. We haven't sought out the work of other countries. We haven't considered the work being done in international standards bodies such as ISO and CCITT. We haven't explicitly considered commercial users. We've limited ourselves to helping provide TCSEC-conforming systems. Many of us believe that the TCSEC criteria are good for commercial applications. Is that hopeful claim just self-serving? We don't know. I wish eminent computer scientists and researchers had gotten together to study the needs of commercial users and drawn up an independent set of commercial security requirements. But they didn't. Kevin Murphy, of British Telecom, is the ISO/IEC JTC1/SC22/WG15 security rapporteur -- he formally represents the international community's concerns and views. In January, Kevin brought several of these to the working group's attention, including our TCSEC biases and lack of attention to ISO activities. The international set seems to consider the document's constant references to the TCSEC work provincial and inconsiderate of other countries' requirements. They also feel we should be more aware and accepting of ISO terminology in the document. Kevin also says our scope is too limited in the CCITT X.400 and X.500 areas. 4. Snowbird June, 1990 Standards Update IEEE 1003.6: Security - 4 - 4.1 Plenary The meeting opened with a short plenary session. This time, the first topic of discussion was the progress of the 1003.6 draft document. Mike Ressler, of Bellcore, accepted the position of technical editor and brought a new draft of 1003.6, which contained work of all but the Audit subgroup. In addition, an electronic copy of the document was available for the subgroups to modify and update during the meeting. The technical editor position had been open since October. No draft was available during this time, which worried us since it prevented us from setting any realistic completion date. With a draft in hand and a technical editor we now project completion in April, 1991. Charlie Testa's absence meant we lacked our usual, detailed report on TRUSIX. (TRUSIX is a DoD-sponsored organization made up of the National Computer Security Center, AT&T, and several other companies.) Rick Sibenaler and Shaun Rovansek, of the NCSC, gave us a brief update, reporting that the audit rationale will be available at the July POSIX meeting and that select experts are now reviewing the draft version of their formal model, which is written in a formal verification language, INA JO. Some of the work of TRUSIX augments the work of 1003.6 -- pursuit of a formal security model and descriptive, top-level specification, and a mapping between them, for example -- but some overlaps. I'm still puzzled over why TRUSIX has pursued audit and DAC mechanisms when 1003.6 is doing the same work. (Another challenge: can anyone out there tell me?) To their credit, TRUSIX is accomplishing their goals much faster than 1003.6. For example, Charlie reported in January that the TRUSIX DAC work is already complete. This speed may be at the expense of POSIX, since many very good people in both organizations are forced to split time between the two unnecessarily. Mike Ressler reported on the networking/administration/security liaison group, which spends an afternoon at every POSIX meeting discussing mutual concerns of these three independent working groups. Here are the liaison group's goals, in areas of our common interest: + identify areas of overlapping or missing coverage, + provide an interface to ISO, ECMA, CCITT, and other international bodies, and + exchange ideas and discuss related issues. Peter Cordsen, of DataCentralen (Denmark), presented Danish security requirements. They define three levels of sensitivity, with criminal data among the most sensitive. There was no specific comparison to either the U.S. TCSEC or the emerging European security criteria. Peter suggested that the security working group begin addressing authentication, a position that received much support from other representatives. June, 1990 Standards Update IEEE 1003.6: Security - 5 - 4.2 Draft work After the plenary, we worked on the document in subgroups. 4.2.1 Discretionary_Access_Control_(DAC) The group put together a new outline for the general and introductory sections of the draft and rewrote those sections to follow the new outline. They also resolved several issues: + There will be only one type of default ACL, not the previously planned separate types for regular files and directories. + A mask entry type has been added to provide a mechanism that temporarily overrides all other entries without actually changing their values or deleting them from the ACL. The feature also fits nicely with the current plan for ACL interaction with the old POSIX permission bits. + The user model for both default and actual ACLs will be the same. (The internal representations are undefined.) System interfaces will be the same, too. A flag will be added to any interfaces that need to be able to distinguish the two. 4.3 Audit Olin Sibert, of Sun, presented a new, ``compromise'' audit proposal, based on an earlier one by Kevin Brady, of AT&T, and Doug Steves, of IBM, which he thought resolved some of the earlier work's problems. The working group accepted Olin's proposal with minor changes and incorporated it into Draft 6, which was distributed in the IEEE May mailing. 4.4 Mandatory Access Control (MAC) Since Kevin Brady, the MAC chair, was participating in the Audit discussion, and Chris Hughes, of ICL, the acting chair, was also absent, Joe Bulger, of NCSC, ran the meeting. It is still unclear who will chair the MAC subgroup. Through the joint efforts of Bellcore and AT&T, the MAC draft had been translated from a proprietary, word-processor format into the [n|t]roff + POSIX-macro format required for inclusion in the draft standard. The MAC draft's contents had been stable for several meetings, so the group spent the entire week changing the document. This group seems to be having the most difficulty getting its job done. There doesn't seem to be as much discussion and active participation in the MAC group as the others. June, 1990 Standards Update IEEE 1003.6: Security - 6 - 4.5 Privileges No functional changes were made to the privileges material at this meeting, but significant changes were made to the rationale. The group also firmed up concepts and disambiguated functional ambiguities. 4.6 Networking, Administration, and Security Liaison The networking/administration/security liaison group held its second meeting Wednesday afternoon. The meeting, chaired by Mike Ressler, started by reviewing the group's scope and goals. Since there had been no ISO meeting since the January POSIX meeting, Yvon Klein, of Group Bull (France), didn't have anything new to say about ISO's security activities. As part of the group's continuing efforts to and identify problem areas, the system administration group and two networking groups gave presentations on their work. Steve Carter, of Bellcore, presented the scope and charter of the system administration group, 1003.7, and explained their use of an object-oriented paradigm. Jim Oldroyd, of the Instruction Set, followed this by presenting the work of 1003.7's interoperability subgroup. Kester Fong, of General Motors, gave an overview of the FTAM group. He left us with the impression that there wasn't much room for collaboration, but we'll surely need to review the relationship between the file-system's security semantics and those of FTAM. Jason Zions, of HP, gave one of the most interesting and aggressive presentations of the day, on the work of the Transparent File Access Group, which included a preliminary list of issues that 1003.8 feels need to be reviewed. Finally, David Rogers, of ICL (Britain), gave a presentation on the European security criteria. He predicted harmonization by June, 1990 of the work of Britain, France, Germany, and Holland. The European criteria will define separate levels of functionality and assurance. There will be ten classes of functionality. The first five are hierarchical and are similar to the U.S. Orange-Book criteria; the remaining five address particular security needs, such as integrity, availability, and networks. There are seven classes of assurance. A product evaluated under these criteria is likely to receive a rating from the first five functional classes, one or more of the next five functional classes, and an assurance rating. June, 1990 Standards Update IEEE 1003.6: Security - 7 - 4.7 Final Comments With the short plenary session, the availability of the draft document in electronic form, and the presence of many lap-top systems to work on, this meeting was one of our most productive. The group seems to have picked up enthusiasm from the knowledge that our work is coming together and the end is in sight. June, 1990 Standards Update IEEE 1003.6: Security Volume-Number: Volume 20, Number 55