All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul McNabb <mcnabb@argus-systems.com>
Cc: selinux@tycho.nsa.gov
Subject: Re: Not quite MLS.
Date: Wed, 19 Aug 2009 14:53:59 -0700	[thread overview]
Message-ID: <4A8C7477.4010807@schaufler-ca.com> (raw)
In-Reply-To: <4A8AD3A1.30109@argus-systems.com>

Paul McNabb wrote:
> Glenn is right that the Mitre LEF can only work on a per-system rather
> than a per-user basis for disallowing certain classification and
> compartment/category constraints.  The only MLS system that I know of
> that did what you are asking for is the old Addamax B1st system.  That
> MLS system had user clearances as a set of labels and label ranges
> that allowed a specific user clearance to be something like:
>
> { unc - ts:1,2,3; unc:4 - sec:4 ; con:5 }

Trusted Irix also allows ( allowed? :-( ) a list of ranges of labels.
Trix uses something like:

    user:label1:label1 label2 label3...label127 label200 label300...label400

to say that user would get label1 if he didn't specify a login label
and that he could ask for label1, label2, label200, any label that
dominated label3 that was also dominated by label127 or any label that
was dominated by label300 that was also dominated by label400.

The internal structure of Trix labels is sufficiently complicated that
no one ever spelled them out, they always used aliases.
>
> which would allow the user to be cleared from unc to ts in categories
> 1, 2, and 3 but have only a unc to sec clearance in category 4 and
> only con for category 5.
>
> Strictly speaking, a system can be "fully MLS" regardless of the
> clearance functionality.  Some MLS systems have been built (and
> bought) without any notion of a user clearance at all, particularly
> some MLS systems built to the first generation of TCSEC requirements.

The Trix kernel never had a notion of clearance. All clearance
processing was done in user space. Trix did get a B1 and an LSPP.
Sold pretty well, too. Never did use the Mitre/DIA encodings, either.
At first Mitre wouldn't let us have it, then we figured out we could
live better without it. Not having it may have cost a deal or two,
but we certainly made up for it with simpler interfaces.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2009-08-19 21:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-14 21:30 Not quite MLS rob myers
2009-08-17 11:40 ` Stephen Smalley
2009-08-17 21:38   ` rob myers
2009-08-18  0:40     ` Glenn Faden
2009-08-18 14:19       ` rob myers
2009-08-18 16:15       ` Paul McNabb
2009-08-19 21:53         ` Casey Schaufler [this message]
2009-08-18 14:34     ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A8C7477.4010807@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=mcnabb@argus-systems.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.