Announcement: TrustedBSD Extensions Project

[jont at us.ibm.com]

[ FYI: Nicely html'd version of the rainbow series, however do you trust
the site ...
     http://www.AntiOnline.com/archives/text/rainbow_books/  ]

| - PP
> - JT

Someone claiming to be Phil Pennock <phil at globnix.org> wrote:

Typing away merrily, jont at us.ibm.com produced the immortal words:

> | 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?

Mandatory controls would (should ?) allow a finer granularity of control
than
_pleb_ or _god_.  The passwd program can do far more than just edit the
password file, we hope (and by careful examination of the source code +
gcc,
and frequent prayers establish some small measure of trust) that it won't
in general.


> | 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.

What falls apart ?
Which alternative to user-based discretionary access control (UBAC) are
you presuming ? (I think capabilities ? But its a big jump from the current
thread, and a bigger jump from current *nix models.)


>  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?

The principle of least privilege - you surrender only that trust you gave
the context.  So you must be able to define contexts that are less than
your own, and you must be able to verify certain facts about them.

|  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.

In the end it all comes down to trusted code enforcing boundaries and
transitions
between boundaries.
Theoretically we could rely on trusted programs, except that the assurance
task of
verifying them all is too big (cf Open BSD).  Note this does not mean
verifying
critical ones is not highly desirable.

If we reject this approach in favour of an intepreter for a restricted
model which
can then be carefully evaluated before being included in the TCB, we get
two questions:
1) how restricted a model ?
2) user space or in-kernel ?

Personally I favour microkernels over monolithic because, well,
less code has to be totally trusted.


The question over what models is 'open', how open depends on who you talk
to.

Some people favour models based on rule based systems, since these can be
turing compelete, but they aren't as simple as user-based ACLs.
[ Hopefully a security domain specific language will be easier/simpler than
a general
programming language, but if its turing equivalent ... ]

I tend to believe table or set based models are a good compromise between
simplicity and
functionality.

...

| 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 are too many sources :-)
Fortunately many good ones are only the price of a book (each).

I tend to like Edward Amaroso's Fundamentals of Computer Security, of
course
Morrie Gasser's Building a Secure Computer System is now out-of-print
(anybody got a copy they
want to sell ?) and Dieter Gollmann wrote one, which looked like it might
be okay (the draft
I saw was clearly a draft).

The orange book has been obsoleted by the Common Criteria 2.1 (ISO ...).

The is lots online:
For currently invogue security models you probably want to look for
  role-based access control (RBAC) - be careful this is a comparatively new
class of models
      which is undergoing (in my view premature) standardization
  lattice-based access control (LBAC) - also bell-lapadula, or multilevel
security
  type enforcement (TE) - also domain and type enforcement
  GFAC - generalised framework [rule based] for access control
     (note there is a linux project to implement this)

There are also several integrity models by various people I'd recommend:

Clark, D. D., and D. R. Wilson, A Comparison of Commercial and Military
Computer Security Policies
    In Proc. 1987 IEEE Symposium on Security and Privacy", April 1987. pp.
184-194.

Boebert, W. E. and R. Y. Kain, A Practical Alternative to Hierarchical
Integrity Policies
    In Proc. of 8th National Computer Security Conference, Gaithersburg,
MD, 1985. pp 18-27


There is a good tutorial on lattice based access control by Ravi Sandhu
http://www.list.gmu.edu/journals/computer/pdf_ver/i93lbacm.pdf.
And perhaps his paper on RBAC
http://www.list.gmu.edu/journals/computer/pdf_ver/i94rbac.pdf

Of course, I wouldn't actually recommend anything by Tidswell et al. :-)
Certainly not anything from ACISP'98 (LLNCS 1438) or ACM RBAC'99 or ACM
RBAC 2000, especially
since camera ready of the latter is not ready.

- JonT



---
Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532

Email: jont at us.ibm.com   Voice: +1 914 784 7550


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message