Re: Rule Set Based Access Control (RSBAC)

From: Stephen Smalley <sds@tislabs.com>
Subject: Re: Rule Set Based Access Control (RSBAC)
Date: Fri, 6 Apr 2001 08:06:48 -0400 (EDT)

Next Article (by Date): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Previous Article (by Date): Re: Rule Set Based Access Control (RSBAC) Simone Fischer-Hübner
Top of Thread: Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Articles sorted by: [Date] [Author] [Subject]

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

Most policies require some degree of dynamic behavior, e.g. as
user authorizations change, and some policies must revoke
permissions dynamically based on the history of operations 
performed or in response to some event.  So the idea is to provide the
necessary infrastructure to support policy changes at runtime rather than
requiring that the system be restarted in order to ensure that accesses
are revoked properly.

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

As I mentioned in my reply to Amon, most of the domains deal with
system processes and programs that require special access rights.
For users, related domains are grouped into roles, and only a small
number of distinct roles are defined.  If a system upgrade involves
adding new system processes, privileged programs, or sensitive files,
then you would naturally want to update your configuration to address
those entities.  Also, note that this is simply an example policy
configuration.  Administrators are free to find their preferred
balancing point between fine-grained protection (with the cost
of complexity) and ease of management (with the cost of quality
of protection).  But my preference would be to encourage the
development of tools to ease the management without sacrificing
the granularity of protection.

> 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 not sure what you mean by auditing in this context.  
The policy compiler can also be used to load a binary representation
and issue queries against it.  You can use it to test and debug
the policy before installing it (and also to test and debug a
copy of the security server in user space).  I suppose we could
have it "disassemble" a binary representation back into the
human-readable form, or do automatic comparisons with human-readable
forms.

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

You could model n-person control by defining a n-stage pipeline,
something that TE is naturally suited for.  But I'm curious about
the real intended use for your policy.  Do you really want n-person
control over some operating system service (e.g. a file access), or do
you really need n-person control over some application service?  If
you need it for some application service, then you are likely to need
enforcement support in the application itself, using the OS mechanisms
to protect the application from tampering or bypass and to confine the
damage that might occur if the application mechanism fails.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




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