Re: Plans with RSBAC

From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: Plans with RSBAC
Date: Mon, 18 Oct 1999 09:07:46 -0400 (EDT)

Next Article (by Author): Re: RC separation of duty "Paul D. Robertson"
Previous Article (by Author): Re: Plans with RSBAC "Paul D. Robertson"
Top of Thread: Plans with RSBAC ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Plans with RSBAC Stewart Robert Hinsley
Articles sorted by: [Date] [Author] [Subject]

On 18 Oct 1999, A. Ott wrote:

> The current system default for everything in MAC is unclassified. The only  
> reason root has top-secret is that this is part of the standard useraci  
> file. You could change the default file/dir level in aci_data_structures.h  
> to e.g. confidential, so a new user could not access anything.

Ok, this sounds good, I'll give it a try for sure.

> With RC, the default role is 0. Setup rights for this role to something  
> harmless, make another working role and require the role of a new user to  
> be set to this by roleadmin for real working.

Great, with these changes, it should be possible to ensure that a new
user added to a compromised system is useless :)

> > Secondly- I'm still working with some ideas on what I like to think of as
> > "two man missile key" control, where it takes two people to launch a
> > given capability or role.  Ideally, that would include some mechanism to
> > "half-grant" a role, MAC or privilige to a user, with the other
> > (preferably configurable in number, but two works for me initially)
> > grantor assigning the other half of the role.  This would essentially
> > mean a mechanism where security officer would be split into multiple
> > pieces, so that the role of granting roles wouldn't be tied to a specific
> > person.  For instance, if you had a security officer s2-1 and a second
> > security officer s2-2, s2-2 could half-grant access to the system, or to
> > a MAC to user "newbie."  Then S2-1 would have to half-grant the same
> > access to newbie for newbie to be able to {assume a role, access
> > information at a MAC...}  Ideally, it would, after initial configuration
> > take both administrator keys to add a new administrator to the mix.
> > Possible "2 of 3" would be a better rule, so that there could be an ID in
> > the safe with credentials should S2-1 leave...
> >
> > (Hmmm, I'm not sure that makes sense to anyone but me, questions welcomed)
> 
> In fact, something similar is part of PM model already. Dataprot sets a  
> timestamped token, which allows secoff to perform an administration  
> function with parameters in the token.

This soulds very good for an initial cut, will it scale to the other modules?
Timestamped tokens are something that I'd not thought about, but that 
makes it even better.

> It would be possible to set a threshhold value for RC, how many different  
> role admins have to set the new role value before it is really changed. We  
> already have different attributes for changing role rights (admin_type =  
> role_admin) and user roles (right MODIFY_ATTRIBUTE on user targets *or*  
> admin_type = role_admin (the latter could be removed)). It is a bit  
> difficult to find a good separation of duties here.

I've been thinking more about this, and I think it's a good deal to have 
some sort of threshold for certain roles/MACs where a quorum of admins 
need to grant a specific right, but perhaps have an overriding admin role 
for the "in the safe in case someone leaves" thing.  This would allow a 
new workflow models, like supervisory approval, split responsibilities, 
realtime audit, as well as start to be an enabler for some interesting CA-type
things where the system holds the main key without any admin access (hence the
need for the no single user to be able to grant access to the data  - I'd 
expect a trusted application to do the signing.)  Perhaps a good start 
would be the ability to make certain roles or capabilities ungrantable - 
so instead of removing secofr, it would be possible to add new users for 
anything but the most critical roles and capabilities after an initial setup?

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

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

Go to Compuniverse LWGate Home Page.