herber@ssc-vax.UUCP (David A Wilson) (07/15/87)
I have been encountering articles on computer security that refer to the US Government Specification document, I believe it is known as the 'Orange book'. The articles refer to requirements for computer security categories referred to by designators such as: C1, C2, B1, B2, A1. There was an article in Unix Review a few months ago about how unix fits in to these categories. According to the article, Unix can satisfy levels up to C2 without any significant changes, but no higher. The problem occurs at level B1 which requires access-lists for files. The issue I would like to discuss is why are access-lists considered more secure that unix-style owner/group/other permission(as the specification seems to apply)? Are there any studies that show this? I can see no reason that unix permissions cannot provide equivalent level of data access protection to access-lists. With multiple group membership, such as provided in BSD Unix, file access can be controlled to any level desired. Unix should be able to meet all other criteria specified in the document without much change, if this requirement were changed to allow unix-style permissions. Does anyone have any other thoughts on this subject? David A. Wilson uw-beaver!ssc-vax!herber -- David A. Wilson uw-beaver!ssc-vax!iscland w
lamaster@pioneer.arpa (Hugh LaMaster) (07/15/87)
In article <1334@ssc-vax.UUCP> herber@ssc-vax.UUCP (David A Wilson) writes: >significant changes, but no higher. The problem occurs at level B1 which >requires access-lists for files. > The issue I would like to discuss is why are access-lists considered >more secure that unix-style owner/group/other permission(as the specification >seems to apply)? Are there any studies that show this? I can see no reason Access lists are much more secure, in practice, than owner/group/other. I have had a wide experience on many other systems before coming to Unix, and I can say that not having access lists is a severe handicap. In a "normal" operating system with access lists, files are readable only by the owner or by certain O/S utilities that must be run from the console. Other files must be given permission on a file or directory basis before anyone can read them. Since security is on a file basis instead of on a person basis ("group" basis), it is much easier for users to, by default, protect all their files and still give permission to those who need access. If you don't see the distinction, you may not have worked on a system with hundreds of users, unknown to yourself, with some of them legitimately presumed to be "suspicious", and yet where you still had to share SOME files with some users who also may not be ENTIRELY trustworthy. Whenever you have to share data with people but not others on an individual basis (e.g. licensed source code is always a good example) on a large system where most people are strangers, then you have a problem. To summarize, the main problem is not penetration from the outside, but penetration from the inside on a system with a large number of strangers. A second point. Most unix security problems actually arise because SUID and known files were used to add functions instead of adding system calls. There is no known way to add O/S functions securely without adding system calls in a conventional system. It MAY be possible in a capability based system. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility")
rrs@amdahl.amdahl.com (Bob Snead) (07/15/87)
In article <1334@ssc-vax.UUCP>, herber@ssc-vax.UUCP (David A Wilson) writes: > According to the article, Unix can satisfy levels up to C2 without any > significant changes, but no higher. The problem occurs at level B1 which > requires access-lists for files. > Access control lists are one mechanism for implementing what is called discretionary access controls, permission bits is another. Such controls are required for C-level certification according to the TCSEC (the orange book). So, as far as discretionary access controls, UNIX could be certified at the C2 level. Permission bits, however, are viewed as a cumbersome mechanism to control access at the granularity of an individual. Access control lists is a much cleaner mechanism. At the B level mandatory access control is required (Top Secret, Secret, etc) in addition to discretionary access control (and lots of other stuff). Claimer: "There is no way of exchanging information that does not demand an act of judgment." - Jacob Bronowski Disclaimer: If you perceived opinions in what I have written they are probably your own and certainly not Amdahl Corp's. Bob Snead Future Computing Technologies Amdahl Corp. UUCP: ..!{ihnp4, hplabs, amd, sun, ...}!amdahl!rrs
nelson@ssc-vax.UUCP (Paul W. Nelson) (07/16/87)
in article <1334@ssc-vax.UUCP>, herber@ssc-vax.UUCP (David A Wilson) says: > > The issue I would like to discuss is why are access-lists considered > more secure that unix-style owner/group/other permission(as the specification > seems to apply)? Are there any studies that show this? I can see no reason > that unix permissions cannot provide equivalent level of data access > protection to access-lists. With multiple group membership, such as provided > in BSD Unix, file access can be controlled to any level desired. > The problem with this approach is that it requires the system administrator to set up new groups. How many groups do you think would be required to cover each file that needs access-list type protection? It could be very significant, not to mention cumbersome trying to remember which group goes with which file. Access control lists are not really required until you get to a B3 level of assurance. The requirements for C2-B2 say that the user must specify and control sharing of objects. Groups, name lists or both can be used, and the user must be able to limit propagation of access rights. The real sticky point in getting into the B category is the concept of mandatory access control. B level systems must "enforce a mandatory access control policy over all subjects and storage objects under its control". The subjects and objects must be assigned sensitivity labels that are a combination of hierarchical (unclass, secret, top secret, etc.) and non-hierarchical (no foreign, COMSEC, NATO, etc). By the way, the orange book is now DOD 5200.28-STD "Department of Defense, Trusted Computer System Evaluation Criteria". Paul Nelson uw-beaver!ssc-vax!ssc-bee!nelson
langz@athena.mit.edu (Lang Zerner) (07/16/87)
In article <1334@ssc-vax.UUCP> herber@ssc-vax.UUCP (David A Wilson) writes: >The articles refer to requirements for computer security categories >referred to by designators such as: C1, C2, B1, B2, A1. There was an article >in Unix Review a few months ago about how unix fits in to these categories. >According to the article, Unix can satisfy levels up to C2 without any >significant changes, but no higher. The problem occurs at level B1 which >requires access-lists for files. > > The issue I would like to discuss is why are access-lists considered >more secure that unix-style owner/group/other permission(as the specification >seems to apply)? Are there any studies that show this? I can see no reason >that unix permissions cannot provide equivalent level of data access >protection to access-lists. With multiple group membership, such as provided >in BSD Unix, file access can be controlled to any level desired. > > Does anyone have any other thoughts on this subject? I agree with david that the owner/group/other permissions are sufficient. All that is needed to obtain access lists for files is to have a corresponding group for every file in the system. To implement file access lists using the permissions system, all that would be necessary would be to have each file have its own entry in /etc/group, along with the appropriate permissions. For example, if user joeschmoe creates a file called 'libX.a' in /usr/joeschmoe, an addition would be made to /etc/group consisting of a line reading: /usr/joeschmoe/libX.a::<groupnum>:joeschmoe (where <groupnum> is a unique group number such as the highest existing group number + 1; if /etc/group needs all alphanumeric group *names*, unique names can be generated in a similar manner) and default permissions -rwxrwx---. To add people to the access list for the file, simply append their names to the end of the /etc/group name of the file. So to add user jruser to the access list for /usr/joeschmoe/libX.a, you simply add to the above /etc/group line to yield: /usr/joeschmoe/libX.a::<groupnum>:joeschmoe,jruser Using this system, the owner of the file can deny access to the file to anyone in the group, or allow access to the world, by using chmod. Two ways exist to add users to the access list: (1) to add specific users, contact a superuser (who presumably is trusted to be responsible for the security of the system), since only root can modify /etc/group; and (2) if you created the file, use chmod to allow world access. If it is not appropriate to allow nonroot users to allow world access, root creates the file. The only modification to unix per se to implement this system is one that would create the entry in /etc/group (i.e. generating a unique group number, etc) whenever a file is *first* created. After that, all that would be needed is a set of superuser utilities for effecting the modifications to /etc/group, such as: addaccess <username> <filename> (which would add <username> to the access list for <filename>) along with other utilities for removing access, etc. There will probably be arguments regarding disk space usage, etc, but remember that no matter how you slice it, you've got to put the access lists *somewhere*. Also, I don't know how difficult it would be to make that one modification that adds the /etc/group entry at first creation of a file. The only seemingly efficient thing would be to modify whatever routine creates the directory entry. Any thoughts, unix hackers and wizards? Is it really as simple as it seems? ------------------------------------------------------------------------------ Lang Zerner ARPA/Internet: langz@athena.mit.edu UUCP/Usenet: ...{mirror|seismo|blblbl}!mit-eddie!langz@athena USPS: P.O. Box 247, M.I.T. Branch, Cambridge, MA 02139 Phone: 617/628-7156 "Nothing is ever accomplished by a reasonable man." -- George Bernard Shaw ==============================================================================
langz@athena.mit.edu (Lang Zerner) (07/16/87)
In article <860@ssc-bee.ssc-vax.UUCP> nelson@ssc-vax.UUCP (Paul W. Nelson) writes: >in article <1334@ssc-vax.UUCP>, herber@ssc-vax.UUCP (David A Wilson) says: >> I can see no reason >> that unix permissions cannot provide equivalent level of data access >> protection to access-lists. With multiple group membership, such as provided >> in BSD Unix, file access can be controlled to any level desired. > >The problem with this approach is that it requires the system administrator >to set up new groups. This is a real problem, but it could be easily gotten around by implementing access-group utilities which had write permision to /etc/group, but did not give that permission to their invokers. For example, adduser <username> <filename> could make sure that it's caller owns the file <filename> before adding <username> to the access group for <filename>. That way, the user would not have the ability to arbitrarily diddle /etc/group, but would nevertheless be able to alter the access groups to his or her own files *without* contacting a system administrator. >How many groups do you think would be required to >cover each file that needs access-list type protection? It could be very >significant, Not relative to the number of access lists you would need to provide the same protection. You would need exactly one group for each file which had access list protection, just as you'd need exactly one access list per file in an access list-based system. >not to mention cumbersome trying to remember which group goes >with which file. Quite simple, really, if you just use group names like "/usr/jruser/libX.a". Remember that /etc/group is an ASCII file, so it's not a problem to use slashes and punctuation characters (except the colon) in group names. ------------------------------------------------------------------------------ Lang Zerner ARPA/Internet: langz@athena.mit.edu UUCP/Usenet: ...{mirror|seismo|blblbl}!mit-eddie!langz@athena USPS: P.O. Box 247, M.I.T. Branch, Cambridge, MA 02139 Phone: 617/628-7156 "Nothing is ever accomplished by a reasonable man." -- George Bernard Shaw ==============================================================================
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/16/87)
In article <1144@bloom-beacon.MIT.EDU> langz@athena.mit.edu (Lang Zerner) writes: <In article <1334@ssc-vax.UUCP> herber@ssc-vax.UUCP (David A Wilson) writes: <> The issue I would like to discuss is why are access-lists considered <>more secure that unix-style owner/group/other permission(as the specification <>seems to apply)? < <I agree with david that the owner/group/other permissions are sufficient. All <that is needed to obtain access lists for files is to have a corresponding <group for every file in the system. To implement file access lists using the <permissions system, all that would be necessary would be to have each file have <its own entry in /etc/group, along with the appropriate permissions. For <example, if user joeschmoe creates a file called 'libX.a' in /usr/joeschmoe, an <addition would be made to /etc/group consisting of a line reading: < </usr/joeschmoe/libX.a::<groupnum>:joeschmoe This is a joke, right? There are two problems right off the bat. One - you've just limited yourself to 64K files on most systems - and that's using negative group ids, at that. Two - the maximum number of groups any user can be in is *very* small. Say, 32 maximum. For SysV people, it's 1. Any system small enough to live with the 64K files restriction is probably running SysV (IBM PC based). This means that if you need to compare two files, neither of which you own, but both of which you have access to, you've got to create a copy of one, chgrp to the other, then compare them. Likewise, having to find a superuser to give someone else permission to read the file is going to make your superusers very busy - and very unhappy - on anything but a small system.. <The only modification to unix per se to implement this system is one that would <create the entry in /etc/group (i.e. generating a unique group number, etc) We won't bother mentioning having to support gid's as long as inode numbers plus device numbers. Nor having a per-process group table large enough to hold as many files as anyone could possibly want to access, so the result would be transparent. <There will probably be arguments regarding disk space usage, etc, but remember <that no matter how you slice it, you've got to put the access lists <*somewhere*. Nah, I figure keeping track of all the files in the system should only cost 100 Meg or so for our large system. I've got four file systems with that much free - no sweat. Even the limit on total number of files can be gotten around (have the "addaccess" command chmod the file and create the new group). But the small number of groups each user can belong to going to be murder. In other words, while the unix system is theoretically as powerfull as access lists, it leaves a lot to be desired in practice. <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
nick@capra..UUCP (Nick Whyte) (07/18/87)
In article <1144@bloom-beacon.MIT.EDU> langz@athena.mit.edu (Lang Zerner) writes: >In article <1334@ssc-vax.UUCP> herber@ssc-vax.UUCP (David A Wilson) writes: ... >> The issue I would like to discuss is why are access-lists considered >>more secure that unix-style owner/group/other permission(as the specification >>seems to apply)? Are there any studies that show this? I can see no reason ... >group for every file in the system. To implement file access lists using the >permissions system, all that would be necessary would be to have each file have >its own entry in /etc/group, along with the appropriate permissions. For ... This would only allow one permission matrix for anyone besides owner and world. With access lists you can grant different permissions to different groups. EMBOS (Elxsi's proprietary OS) has a powerful access list scheme which includes passwords (as a fake group) to qualify for different access rights, and program lists, where some groups are required to be running one of the specified programs to acquire the specified access. The down side is the complexity of the security mechanism is difficult for naive users to understand. We have added simple security commands to provide basic "Do what I mean" functions, but this does not prevent them from using the full feature commands as an experiment and getting bizarre security behavior (to them). The higher probability of creating wrong security matrices could be interpreted as an increased security risk, though the system administrator could build some fire walls around different "groups" of users. -- Nick Whyte {ucbvax|ihnp4|seismo}!sun!elxsi!nick Elxsi Disclaimer: I don't know if Elxsi agrees with what I said since I didn't bother to ask anyone.
root@hobbes.UUCP (John Plocher) (07/18/87)
+---- Lang Zerner writes the following in <1144@bloom-beacon.MIT.EDU> ---- | >The articles refer to requirements for computer security categories | > The issue I would like to discuss is why are access-lists considered | >more secure that unix-style owner/group/other permission(as the specification | | I agree with david that the owner/group/other permissions are sufficient. All | that is needed to obtain access lists for files is to have a corresponding | group for every file in the system. To implement file access lists using the +---- ^^^^^^^^^^^^^^^^^^^^^^^^ AAAArrrrggghhhh! Some points which show that this issue is not so simple: Hobbes is (for most intents) a single user System5 machine with 70 Mb of disk. It has more than 10,000 files. If there were 10,000 entries in the groups file the system would crawl! For every open(), access() ... the OS would have to check the group file. Every file creation, deletion, and access mod would have to access and change this file. It would have to be locked to keep 2 priv'd users from changing it out from under each other's feet. What about deadlocks, recursion (unless you want to make the group file a special case, how does one check to see if one has permission to read the group file?) ( What this all says is that using regular files for access lists involves tradeoffs which may or may not be justified) Using ugo perms how does one specify that: 1/2 :-) Fawn can read and delete, but not add or modify Iran.data, Casy can create and read it but not modify or delete it, house and senate can not even find out that the file exists, Ron can only read and append to it, and Ollie can create, read, modify, and delete it? Access lists and Capabilities give you a way of doing all this, the user/group/other perms do not. Don't take the second to last paragraph to mean that I think there is something bad about access lists ... :-) John -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU
bzs@bu-cs.BU.EDU (Barry Shein) (07/20/87)
Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) I have a question about this Cn..Bn level security stuff that's slightly off the subject: Does anyone know what the market really is for B level or above secure machines? It seems to me that very few vendors actually implement it. This is not to detract from the original question, just got me thinking. -Barry Shein, Boston University
malcolm@keilir.UUCP (Malcolm Cohen) (07/20/87)
In article <1151@bloom-beacon.MIT.EDU> langz@athena.mit.edu (Lang Zerner) writes: >Not relative to the number of access lists you would need to provide the same >protection. You would need exactly one group for each file which had access >list protection, just as you'd need exactly one access list per file in an >access list-based system. This is not true. In fact the Apollo Domain system uses access lists (ACLs) and *shares* equivalent ACLs automatically -- this sharing is completely transparent to the user (except in the amount of disk space available). Of course you really only need one group for each set of files which had the same access permissions - but then you have lost the 'cute' naming scheme suggested in your next paragraph - putting you back to the horrendous task of managing all those groups; the only real solution to this is not to manage them, i.e. to have the O/S do it for you, ... but then it starts looking like ACLs anyway... -- Malcolm Cohen mcvax!keilir!malcolm Utgardar, Computer Centre, University of Iceland, Reykjavik -----------------------------------------------------------
thompson@calgary.UUCP (Bruce Thompson) (07/20/87)
In article <1151@bloom-beacon.MIT.EDU>, langz@athena.mit.edu (Lang Zerner) writes: > ... <much deleted> > protection. You would need exactly one group for each file which had access > list protection, just as you'd need exactly one access list per file in an > access list-based system. The need for one access-control-list per file is perhaps a misleading statement. It is true, that each file needs an ACL associated with it, but if two files have identical ACLs, then they could share a reference to the same ACL object. This is the way that ACLs are implemented on Apollo machines. We are working on DN3000s. Though I am not speaking from first-hand knowledge, a number of inferences about the way in which the ACLs are implemented may be gleaned from the utilities that are provided. In particular, a utility called SALACL is provided to salvage identical ACL object from the ACL pool. Typically, on our systems, each ACL is referenced by somewhere around 40 different files, providing some potentially significant savings in disk space for the ACL pool. Whenever an ACL is changed, then a new ACL object is created for the file who's ACL was edited. I would have to wonder whether or not the groups idea mentioned previously would be able to provide this kind of 'cacheing' reasonably. ------------------------------------------------------------------------------ Bruce Thompson | Disclaimer? But...but... I didn't University of Calgary, | say anything....really! Well, Computer Science Department | nothing of any interest anyways. (403)220-3538 or (403)220-5109 (office) |
rterrell@ncoast.UUCP (Roger Terrell) (07/21/87)
In article <1334@ssc-vax.UUCP> herber@ssc-vax.UUCP (David A Wilson) writes: > The issue I would like to discuss is why are access-lists considered >more secure that unix-style owner/group/other permission(as the specification >seems to apply)? Are there any studies that show this? I can see no reason >that unix permissions cannot provide equivalent level of data access >protection to access-lists. With multiple group membership, such as provided >in BSD Unix, file access can be controlled to any level desired. Access-lists *in addition* to owner/group/other permissions are more secure because they provide a convienient way to grant a specific user(s) access to a file (or deny access). This is good if I am in one group and want someone in another group--and ONLY that one person--to be able to access a file. I don't have to open it to everyone on the system. It is true that you could probably fudge most situations where access-lists are useful by using regular permissions, but the convienience factor counts too. Roger Terrell UUCP: ...cbosgd!musky2!terrell CSNet: ccterrell%muskingum.edu@relay.cs.net
mack@inco.UUCP (Dave Mack) (07/21/87)
In article <9811@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > Does anyone know what the market really is for B level or above secure > machines? It seems to me that very few vendors actually implement it. > > -Barry Shein, Boston University The main customer for B2 and above is DOD and the intelligence folks. The market there is large, although not in the same class as the commercial market. The number of RFPs specifying security at B2-B3 is impressive. The main reason that very few vendors offer B2-B3 systems is that they aren't ready yet. Honeywell is the only outfit that has successfully produced (i.e., had products certified by the NCSC) systems at B2 or higher: the Multics OS is B2, the SCOMP running STOP 2.1 is rated A1. IBM has announced a B2 secure Xenix for the PC/AT, but I don't believe it's quite ready yet, or at least not certified yet. (They have an SPD out for it.) Essentially all of the major computer manufacturers are scrambling to put together secure versions of their operating systems, but this is a very nontrivial task. It is generally considered impossible to take a system which would be certified at C1-C2 and retrofit enough security to reach B2+. You have to redesign the OS from the metal up. -- ------------------------------------------------------------------------------ Dave Mack (from Mack's Bedroom :<) McDonnell Douglas-Inco, Inc. DISCLAIMER: The opinions expressed 8201 Greensboro Drive are my own and in no way reflect the McLean, VA 22102 views of McDonnell Douglas or its (703)883-3911 subsidiaries. ...!seismo!sundc!hadron!inco!mack ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
stuart@bms-at.UUCP (Stuart D. Gathman) (07/30/87)
In article <151@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: > For every open(), access() ... the OS would have to check the > group file. I believe that the idea of the group file is that the user would be required to do a 'newgrp' command before accessing each set of files with different security. The OS is standard unix. The group file lists the users allowed to newgrp to each group. Thus the claim that standard unix can do the job of access lists (at the expense of considerable user inconvenience). -- Stuart D. Gathman <stuart@bms-at.uucp> <..!seismo!dgis!bms-at!stuart>