Re: Rule Set Based Access Control (RSBAC)

From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Wed, 4 Apr 2001 09:32:21 -0400 (EDT)

Next Article (by Subject): Re: Rule Set Based Access Control (RSBAC) Amon Ott
Previous Article (by Subject): Re: Rule Set Based Access Control (RSBAC) Amon Ott
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Articles sorted by: [Date] [Author] [Subject]

On Wed, 4 Apr 2001, Amon Ott wrote:

> RSBAC design never meant to address such very dynamic behaviour, because policy
> changes were thought of as rare. I also did not like the idea of interfering

If policy changes aren't rare, both administrative overhead and the
oppertunity an administrator has to do bad things (maliciously or
accidently) are higher.   

> Something special in my point of view is that I distrust all user mode
> programs, because they come from unknown sources and might have been modified,
> e.g. trojanized or infected by viruses. In some cases I have to rely on them,
> e.g. for the (insuffient) Linux style user authentication.

I'm curious about this- in a best-case scenerio, how do you see user auth?  At
some point, especially for network aware applications, some user mode
authenticating piece has to be (probably grudgingly) moved into the TCB.
For instance with the Dockmaster II stuff, the modified httpd has to be
part of the TCB because it must be able to allow per-user access.  Is a
known-goodware scan better than a malware scan for such applications?    

> Here we are again with my hardwired policies: They can only be changed by
> modifying the kernel source, recompiling the kernel, installing it and
> rebooting. Most of the steps can be easily prevented by security settings.

That requires them to be rare- which should make auditing such changes
easy.  I'm curious as to how SELinux's auditing process is envisioned to
handle so many permutations and dynamic changes, more on that later
though...

> Real account management should be in the kernel, with strong data protection,
> strong on-disk encryption and setuid limitation by this account management to
> those ids which have been authenticated by the process asking.

The process asking still has the malware problem though doesn't it?  (Has
anyone applied RSBAC to an International kernel to get disk encryption?)

> > The example configuration provided with SELinux defines 70 domains,
> > 188 file types, and 38 other types (e.g. network-related types).

How do the SELinux people expect auditing to take place in such an
example?  Users switching jobs and system upgrades seem to be difficult to
audit effectively with that many default permutations, or am I missing
something?

> > I probably wasn't clear.  With SELinux, you edit the human-readable policy
> > configuration files to set up your policy (starting with the example
> > configuration we provide if you want), then compile that policy
> > into a binary representation and install it.  You can then load
> > the updated policy into your running kernel (if the policy authorizes
> > such runtime changes) using a new system call, or you can reboot
> > (in which case the kernel will load the new policy when it
> > initializes).  My concern was with the need to run a special
> > set of utilities that use a special set of system calls to
> > customize the configuration, as opposed to being able to edit
> > human-readable configuration files.

I assume that the policy compiler is the equivalent of a special set of
utilities, is that a correct assumption?  Syscall auditing is pretty cut
and dried, how do you audit policy changes in SELinux between binary
representations?  How do you deal with an administrator compiling three
different policies then trying to figure out which one to install a week
later? 

I'm also still intensely interested in "two man missile key" stuff.  How
does SELinux handle a model where either multiple adminitstrators should
be necessary to grant access to something, or granting a subset of grant
privs. to a subject is possible to stop the subject from granting all
grant privs. to another subject or itself (which makes it easy to get to
the first part by requiring both privs. to do something)?  Is it possible to 
set up a system where an administrator doesn't have access to certain
targets, and whilst they could grant permissions to other targets on the
same sytem, and even grant access to grant access to other targets, were
still blocked from seeing the data they're not supposed to have access to
(obviously along with their grantees)?  [IOW: is granting rights to grant
rights restrictable in a way other than a binary yes/no fashion?]

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts@clark.net      which may have no basis whatsoever in fact."

-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.