Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.20/text0104.txt

Internet Message Format | 1990-08-02 | 1.9 KB

From:  [e-mail] (James Buster)

In article <[e-mail]> [e-mail] (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) [e-mail]
  Mad Hacker Extraordinaire    (UUCP)   ...!ames!vsi1!bitbug
---------------------------------------------------------------------

Volume-Number: Volume 20, Number 102