randall@uvaarpa.Virginia.EDU (Randall Atkinson) (06/30/90)
From: randall@uvaarpa.Virginia.EDU (Randall Atkinson) % 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. I disagree. The mechanisms described here are indeed useful in the commercial world. For example, an insurance company happens to own and operate both a bank and a savings & loan and a lot of customers of the banks are owner-members of the insurance firm. The firm is legally obligated not to permit the bank/s&l to have access to information on a customers insurance information or the fact that he/she is a member-owner of the insurance firm without explicit written permission from the individual whose records we are concerned with here. But the insurance agency may legally access the information in the bank/s&l on its customers. This is analgous to the workers at the insurance firm being in a different compartment than the workers at the bank or s&l. Similarly, a bank teller would normally be able to access one level of information and a loan officer or branch manager a different level of information. Please note that my example is real-world rather than one I'm making up. Similarly, firms engaged in product development of one sort or another, for example making computer systems, frequently have projects with different sensitivites and areas of access. Often the goal is deliberately restrict and compartmentalise information about actual costs or profit margin or future plans or two groups with competing approaches to solving customer needs. The management will find it useful to control information access both horizontally and vertically. Certainly the restrictions on write-down and read-up are essential to having a viable security system. It is possible and desirable to talk in terms of having both vertical levels of access and horizontal compartmentalisation without actually using DoD's official classifications whatever they might be. I trust the POSIX draft doesn't talk in terms of Unclassified, Secret, and Top Secret as that would be inappropriate. Randall Atkinson randall@virginia.edu Opinions are those of the author. Volume-Number: Volume 20, Number 68
peter@ficc.ferranti.com (peter da silva) (07/02/90)
From: peter@ficc.ferranti.com (peter da silva) Seems to me that a strict hierarchy is insufficient. What do you do if you have two sub-organisations for which you don't want to allow *either* to be able to give files to one another (say, two different marketing groups setting up separate sealed bids)? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com> Volume-Number: Volume 20, Number 83
bitbug@vicom.com (James Buster) (07/06/90)
From: bitbug@vicom.com (James Buster) In article <768@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes: >Seems to me that a strict hierarchy is insufficient. What do you do if you >have two sub-organisations for which you don't want to allow *either* to be >able to give files to one another (say, two different marketing groups >setting up separate sealed bids)? First, a short overview of MAC: A MAC (Mandatory Access Control) label has *two* components, a hierarchical _level_ and a non-hierarchical _set of categories_. Label A is said to _dominate_ label B if the hierarchical _level_ of label A >= the level of label B *and* the _set of categories_ of label A is a (possibly improper) superset of B's _categories_. The '>=' relationship denotes an ordering that is not necessarily based on the integers or natural numbers, but is intended to imply superiority or supremacy. For a _subject_ (e.g. a UNIX process) with label A to *read* from an object with label B, A must _dominate_ B. For a subject with label A to *write* to an object with label B, B must _dominate_ A. This implies that to both *read* and *write* to an object, A must equal B. An object is created with the label of the subject that creates it. Some security policies may have more restrictive rules. The upshot of all this is that, for your example, each marketing group will have a set of categories that is disjoint (e.g. A is in the category International and B is in Domestic). You can see from the MAC read rule above that this ensures there will be no information flow from Marketing Group A to Marketing Group B. -- --------------------------------------------------------------------- James Buster (Domain) bitbug@vicom.com Mad Hacker Extraordinaire (UUCP) ...!ames!vsi1!bitbug --------------------------------------------------------------------- Volume-Number: Volume 20, Number 102
kingdon@ai.mit.edu (Jim Kingdon) (07/06/90)
From: kingdon@ai.mit.edu (Jim Kingdon)
Thanks for providing some technical details. But can't the level be
made a special case of the set of categories? That is, define
categories CLASSIFIED, SECRET, TOP_SECRET, etc, and give people either
{TOP_SECRET, SECRET, CLASSIFIED} or {SECRET, CLASSIFIED} or
{CLASSIFIED}. Unless I'm missing something, this provides the same
functionality and is simpler.
You might want to post a clarification (or summary of this and other
messages).
Volume-Number: Volume 20, Number 107gwyn@smoke.brl.mil (Doug Gwyn) (07/08/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <793@longway.TIC.COM> From: kingdon@ai.mit.edu (Jim Kingdon) >Thanks for providing some technical details. But can't the level be >made a special case of the set of categories? That is, define >categories CLASSIFIED, SECRET, TOP_SECRET, etc, and give people either >{TOP_SECRET, SECRET, CLASSIFIED} or {SECRET, CLASSIFIED} or >{CLASSIFIED}. Unless I'm missing something, this provides the same >functionality and is simpler. The problem is, that approach could be misadministered to give users {TOP SECRET, CONFIDENTIAL} or other such erroneous category sets (we call them "compartments" rather than "categories"). The intent of the strict CONFIDENTIAL, SECRET, TOP SECRET hierarchy is to rate the relative probable level of damage to the organizational (national) interests if the classified information were disclosed to the wrong parties. The intent of compartments is to enforce the additional requirement, beyond one's rated level of trustworthiness, of having a genuine "need to know" the information. For example, even though I might have a TOP SECRET security clearance, if I have not been specially indoctrinated for access to "special intelligence" then I am not allowed to access even CONFIDENTIAL SI material. You might try to redesign such classification schemes, but these have evolved through many decades of practical experience and seem to be the best we've been able to devise so far. Volume-Number: Volume 20, Number 114