Announcement: TrustedBSD Extensions Project

[Phil Pennock]

Typing away merrily, jont at us.ibm.com produced the immortal words:
> [ administrative - to avoid spammers please make the list subscriber send
> only ]

Perhaps it was deliberate so that people like me could make up their
minds before subscribing?  :^)  There's a strong chance that I will,
even if I mostly just lurk & learn.

> | Hrm - my understanding of mandatory access controls[1] leads me to
> | believe that they're of use where you don't trust everyone in your own
> | party; whether that's their integrity or their competence is not the
> | issue.
> 
> Mandatory access controls are controls which are mandatory from _your_
> perspective ! Sometimes this means mandatory with regard to your personal
> perspective and sometimes it means mandatory with regard to the perspective
> of general programs you run.
> So for example there are mandatory controls over the password file,
> which does not mean you can't change your password using "trusted" paths
> (unfortunately these are frequently inappropriately trusted).

How does this differ from having appropriate discretionary controls on
/etc/shadow on a Unix system?

> | Where you merely have mutually suspicious parties, discretionary access
> | control are, AIUI, sufficient.  Excepting for DoS attacks.
> 
> Wrong.
> If you have mutually suspicious parties there is no way to do either of the
> following using discretionary techniques:
>  a) let them access your data with their code in their security context
>      (you dont want them stealing your data)

Which falls apart the moment that you have the ability to test for the
existence of a key and build a list of valid ones (eg, login programs
which differ the response for invalid accounts vs incorrect
authentication).  This is applicable in any circumstance which comes
immediately to mind; my experience of high security systems, however, is
almost nill.

>  b) let them access your data with their code in your security context
>        (they don't want you stealing their code/algorithms/embedded data)

Whoah.  And I thought covert timing channels were tricky ... okay, I'll
clarify that I'm not questioning the accuracy of your statements here,
just wanting to find out more.

How can you allow the execution of arbitrary code within your security
context without surrendering any trust in the context?  If you're not
allowing arbitrary code, what advantage does this give you over a
set[ug]id interpreter with limited functionality, where the interpreter
is owned by a trusted third party and drops privileges down to the
invokee's context?  After all, as I read it, that's effectively what
you'd be using the MACs to do - with some kind of trusted
context-transition boundary not under the control of either party.

Hrm ... which reminds me:
 <http://www.chiark.greenend.org.uk/~ian/userv/>

> Here even I am sweeping some things under the carpet, because Im assuming
> a user-based discretionary model, and even some things about the model ...

Aside from the TCSEC Orange Book (which I'll freely admit that I need to
re-read) are there any pointers for information which you'd recommend?
Preferably none more expensive than a good book from a bookstore - I
don't fancy spending a few thousand dollars on some standards document.

> There is frequently confusion between mandatory access control and
> multi-level
> (aka lattice) access control, because lattice based controls are always
> mandatory though the inverse is not true.

See above request for pointers to information.

> Just installing Trusted Solaris 2.5 was a chore, I never went beyond that.
> [ Though that was in part a lack of paper documentation - reading the cdrom
> documentation before you have the install running is a problem; the
> documentation CD is not readable on windows (file name conventions). ]

The wrong type of information security?  *coughs*
-- 
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
 We believe in world peace through extortionate license fees."  -Bluemeat
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message