jsh@usenix.org (06/29/90)
From: <jsh@usenix.org>
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 55peter@ficc.ferranti.com (peter da silva) (06/30/90)
From: peter@ficc.ferranti.com (peter da silva) In article <384@usenix.ORG> From: <jsh@usenix.org> (anonymous 1003.6 report) > At the ISO level, there will be no separate security standard. ... > This means every conforming > system will include security mechanisms. You mean, "will include DoD-style security mechanisms". The somewhat simple-minded approach UNIX has had in the past has been remarkably successful, considering. > I like this. Do you? Only if it's possible to turn everything off and go back to /etc/passwd and /etc/shadow, and a superuser. That way when something goes wrong you'll be able to boot from tape or floppy, edit a couple of files, and recover the system. Because something *will* go wrong. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 72
jason@cnd.hp.com (Jason Zions) (06/30/90)
From: Jason Zions <jason@cnd.hp.com> > 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.) Both compartmentalization and classification have commercial applications, but I'm not certain those applications justify the cost and pain. Compartmentalization: Large organizations frequently pursue strategies and practices in the course of daily business that seem, well, contradictory. Things like negotiating with arch-rival companies to sell each of them exclusive rights to a particular technology; at some point, when the higher-ups figure one of the two deals is superior, the other "falls through". For the sake of verisimilitude, one might wish to compartmentalize both negotiation efforts from each other and from the rest of the company on a "need-to-know" basis. One might wish to compartmentalize ones research labs from ones marketing people to prevent the marketing of "futures"; similarly, separating R&D from support organizations can help prevent leakage. All of these can be accomplished by a Simple Matter Of Policy; it is a known phenomena, though, that the large the company the higher the probability of leakage, regardless of policy. MAC can help. Classification: Certain kinds of information are frequently required by law to be controlled with respect to dissemination internally; data related to profit and loss, stock exchange filings, personnel data, etc. Many companies today forbid the electronic storage of such restricted information, and they distribute it by means of printed copies, numbered and signed for, burn-before-reading. It'd be nice to be able to store that stuff on-line, transmit it electronically, while ensuring that those who are not permitted by law to see the information cannot see it. Again, SMOP can accomplish this; however, it's a lot easier to prove someone is or is not an "insider" in the technical sense of the term by showing whether or not they hda access to the relevant data, and by recourse to an audit trail. - - - - > 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. Really? (wince) Musta been a bad day. My apologies to all. Jason Zions Chair, 1003.8 Volume-Number: Volume 20, Number 67
pkr@sgi.com (Phil Ronzone) (07/02/90)
From: pkr@sgi.com (Phil Ronzone) In article <757@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes: >You mean, "will include DoD-style security mechanisms". The somewhat >simple-minded approach UNIX has had in the past has been remarkably >successful, considering. I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient for much serious commercial work due to the "simple-minded" approach it has had. >> I like this. Do you? > >Only if it's possible to turn everything off and go back to /etc/passwd >and /etc/shadow, and a superuser. That way when something goes wrong you'll >be able to boot from tape or floppy, edit a couple of files, and recover >the system. > >Because something *will* go wrong. I don't see what this has to do with security. -- <----------------------------------------------------------------------------> Philip K. Ronzone S e c u r e U N I X pkr@sgi.com Silicon Graphics, Inc. MS 9U-500 work (415) 335-1511 2011 N. Shoreline Blvd., Mountain View, CA 94039 fax (415) 965-2658 Volume-Number: Volume 20, Number 84
peter@ficc.ferranti.com (peter da silva) (07/04/90)
From: peter@ficc.ferranti.com (peter da silva) In article <769@longway.TIC.COM> From: pkr@sgi.com (Phil Ronzone) > I'm not sure what the "DoD-style" words mean, but UNIX has been very deficient > for much serious commercial work due to the "simple-minded" approach it has > had. This may well be true. But for a large set of problems the existing UNIX security approach is quite sufficient. If you don't have the actual hardware secured it's overkill. > >Only if it's possible to turn everything off and go back to /etc/passwd > >and /etc/shadow, and a superuser. That way when something goes wrong you'll > >be able to boot from tape or floppy, edit a couple of files, and recover > >the system. > >Because something *will* go wrong. > I don't see what this has to do with security. I know of at least one case where a hard error in the user database for a system required sending a letter from the president of the user's company to the vendor to get them to explain how to regain access to the system. Security and convenience are opposed goals, and sometimes a system MUST be available. If *all* POSIX conformant systems come with a stronger security system than UNIX installed, it must be possible to set things up so that security system can be defeated and a new system set up with physical access to the hardware. It's acceptable for there to be some magic one-way juju that you can do to put the system into a highly secure state, but it should not come that way. I will neither purchase nor recommend any system I can't get into and rebuild the access system with a boot floppy and the console. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 95
pkr@sgi.com (Phil Ronzone) (07/06/90)
From: pkr@sgi.com (Phil Ronzone) In article <780@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes: >This may well be true. But for a large set of problems the existing UNIX >security approach is quite sufficient. If you don't have the actual hardware >secured it's overkill. I disagree - secure software, from the boot code on, is very effective. >Security and convenience are opposed goals, and sometimes a system >MUST be available. I disagree again -- I think the recent Internet worm is an example of why. -- <----------------------------------------------------------------------------> Philip K. Ronzone S e c u r e U N I X pkr@sgi.com Silicon Graphics, Inc. MS 9U-500 work (415) 335-1511 2011 N. Shoreline Blvd., Mountain View, CA 94039 fax (415) 965-2658 Volume-Number: Volume 20, Number 100
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (07/06/90)
From: sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) In article <786@longway.TIC.COM> From: pkr@sgi.com (Phil Ronzone) >In article <780@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes: >>This may well be true. But for a large set of problems the existing UNIX >>security approach is quite sufficient. If you don't have the actual hardware >>secured it's overkill. > >I disagree - secure software, from the boot code on, is very effective. i have to side with Peter on this. the keywords were "large set of problems" and "quite sufficient" - that doesn't (at least to me) obviate the need for more strict security when the need arises, but for many situations just administering the systems correctly is enough. short of soldiers with M16s at a computer facility door i do not believe that software is any substitute for physical security. it's just one more password that has to be spread around (in case the SSO or whoever) goes on vacation, etc... >>Security and convenience are opposed goals, and sometimes a system >>MUST be available. agreed. >I disagree again -- I think the recent Internet worm is an example of why. now it's my turn to disagree. sheesh, why does the worm have to be brought up everytime security is discussed? it was a BUG that was exploited, and i for one do not think that adding security will do away with BUGs in software. on the contrary, as the complexity of the system is increased by the added software the number of bugs could actually increase, no? and, if people can't administer systems "correctly" now - what's going to happen when the amount of administration required increases due to the files/databasei/etc that "security" will add to the system?? Steven M. Schultz sms@wlv.imsd.contel.com Volume-Number: Volume 20, Number 104
peter@ficc.ferranti.com (peter da silva) (07/06/90)
From: peter@ficc.ferranti.com (peter da silva) In article <786@longway.TIC.COM> pkr@sgi.com (Phil Ronzone) writes: > In article <780@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes: > >This may well be true. But for a large set of problems the existing UNIX > >security approach is quite sufficient. If you don't have the actual hardware > >secured it's overkill. > I disagree - secure software, from the boot code on, is very effective. I'm sure it is. An SR71 is very effective, too, but I find a 747 a whole lot more convenient for a trip to Hawaii. > >Security and convenience are opposed goals, and sometimes a system > >MUST be available. > I disagree again -- I think the recent Internet worm is an example of why. What do you disagree with? That security and convenience are opposed goals, or that sometimes a system MUST be available? And why? (what the internet worm has to do with anything is another question. There have been similar incidents on systems with tighter security requirements, such as the DECNET WANK incident or the CHRISTMAS TREE virus. For that matter I have laid out the preliminary design for a virus that can propogate via Usenet source archives. And from what I know of the internet worm it would have spread pretty near as fast if sendmail didn't run under root permissions. start with a non-sequiter and I guess you can prove anything) -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 108
pkr@sgi.com (Phil Ronzone) (07/09/90)
From: pkr@sgi.com (Phil Ronzone) In article <790@longway.TIC.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes: > short of soldiers with M16s at a computer facility door i do not > believe that software is any substitute for physical security. > it's just one more password that has to be spread around (in > case the SSO or whoever) goes on vacation, etc... Argument of two different fruits here. As an example, we purchased an AT&T 630 (386 PC type machine) to run AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set, as is required the passwords. But they forgot to tell us what the passwords were. Although we had physical possesion of the machine, in a company that also make computers, it would have taken us a while to "boot" the system (i.e., insecurely). And we would have been able to do that ONLY because of the fact that the machine used standard disks with "standard" UNIX filesystems and so on. Whereas the same hardware with normal UNIX would have very vulnerable. A safe protects your money, but if a huge helicopter steals the safe and you have weeks to work on it, you can open it. >>I disagree again -- I think the recent Internet worm is an example of why. > > now it's my turn to disagree. sheesh, why does the worm have to > be brought up everytime security is discussed? it was a BUG that > was exploited, and i for one do not think that adding security > will do away with BUGs in software. on the contrary, as the Eh? That's the WHOLE point of Orange book security and the TCB concept. Those programs would have never made it into the TCB and been able to propagate like they did. Although it is not the best example. The answer was more to WHY would someone want security. Answer is, to control what you have your system do. -- <----------------------------------------------------------------------------> Philip K. Ronzone S e c u r e U N I X pkr@sgi.com Silicon Graphics, Inc. MS 9U-500 work (415) 335-1511 2011 N. Shoreline Blvd., Mountain View, CA 94039 fax (415) 965-2658 Volume-Number: Volume 20, Number 116
peter@ficc.ferranti.com (peter da silva) (07/10/90)
From: peter@ficc.ferranti.com (peter da silva) In article <802@longway.TIC.COM> pkr@sgi.com (Phil Ronzone) writes: [had a B1 UNIX box] > But they forgot to tell us what the passwords were. Although we had > physical possesion of the machine, in a company that also make computers, > it would have taken us a while to "boot" the system (i.e., insecurely). And if you needed to use the machine, you would have been out of luck. For some people that level of security has a negative value. It's that simple. It's not like we're saying "we want all UNIX systems to be insecure", we're saying "we don't want all UNIX systems to come with that level of security". Can't you see the difference? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 120
seanf@sco.COM (Sean Fagan) (07/15/90)
From: seanf@sco.COM (Sean Fagan) In article <802@longway.TIC.COM> std-unix@uunet.uu.net writes: >As an example, we purchased an AT&T 630 (386 PC type machine) to run >AT&T SV/MLS (B1 UNIX). We had AT&T put the software on, and they set, >as is required the passwords. > >Whereas the same hardware with normal UNIX would have very vulnerable. Do you honestly believe that, short of encrypting the data on the disk, sufficient security is going to keep your data "safe" if your machine is (physicially) compromised? Uh-huh. -- -----------------+ Sean Eric Fagan | "Just think, IBM and DEC in the same room, seanf@sco.COM | and we did it." uunet!sco!seanf | -- Ken Thompson, quoted by Dennis Ritchie Volume-Number: Volume 20, Number 129