Re: RC separation of duty

From: "Paul D. Robertson" <proberts@clark.net>
Subject: Re: RC separation of duty
Date: Sat, 30 Oct 1999 15:24:56 -0400 (EDT)

Next Article (by Subject): Re: RC separation of duty Vadim Kogan
Previous Article (by Subject): Re: RC separation of duty ao@morpork.shnet.org (A. Ott)
Top of Thread: RC separation of duty ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: RC separation of duty Vadim Kogan
Articles sorted by: [Date] [Author] [Subject]

On 30 Oct 1999, A. Ott wrote:

> So you will probably be the first one to use the separation of duty  
> features. I'd like to get lots of ideas for improvement, practical  
> experiences, etc.

I'm hoping to be.  The commercial trusted *nix vendors I've dealt with in 
the past haven't been able to provide what I consider sufficient 
seperation of duties in the offerings I've looked at.  

I'd like to move to a truly distributed administration model, but I can't 
open the trust gates wide enough at the start without seperation or creating 
an only-in-emergency-usage super-user or security officer account.  This 
obviously doesn't scale the security model well at all if the model 
includes some limitation of granting rights.  

Your solution looks to me to solve the first part of the trust issue in 
exactly the way I'd like it to - start with the generic model, then open up 
some granting, and finally remove the 'super-grantor' role from the 
system *without* requiring the reboot of the system into maintenance mode 
to add additional administrators at any level.  24/7 production setups 
have really been outside the bounds of traditional trusted OS models if 
it was thought they'd need to do more than a single well-bounded thing 
and still have 100% audit/protection if the highest level of 
administrator/security officer left. 

My level one folks can have enough administrative power to run 
the system, the level two folks can have enough power to generate new 
admin users, and now more trusted level two folks and/or my front-line 
level three folks can have the ability to create new level two IDs 
without having the ability to compromise the system's integrity.  It's 
will now be possible to mark a system as having a complete model, and remove 
the compromise ability without removing the administrative capability to 
add new users to the existing role framework, including adding new level 
three accounts.  

This is a model I've been trying to implement for a while, but haven't 
had the time/software to start extending a TCB implementation enough to 
support it.  I'm more than ready to see how it operates in the real world 
though, so my time to implement will be as short as I can get it.

> The whole concept just evolved in my head to be something that might work,  
> but I am not yet sure about all the consequences.

I keep going over past designs in my mind, and the only extension I can 
see as useful is to be able to stop the grantor from adding themselves 
to a role.  In your current scenerio I'm not sure if the grantor can 
grant themselves access to a role they have grant authority over, in some 
models that wouldn't be the best thing - though for most people it's 
probably not an issue.  With the addition of the seperation, I'm sure that 
it's still possible to build systems that don't allow that by using daemons 
with roles that aren't delegated to the current grantors on the system.  

The initial cut sounds like it'll fit my proxy scenerio perfectly.  The 
subsequent work I was looking towards is a certificate authority.  I'd 
like to be able to build certificate issuers that don't need to have 
their root certificates revoked if a trusted administrator leaves.  For 
that, I need to ensure that the administrators don't have access to the 
private side of the root cert.  It's looking like a trusted daemon will 
work in that case though as long as I remove the ability to grant that 
role to anything once the daemon has been given it.

I've never gotten the seperation that I've wanted in a system before, so 
I'm sure I'll have some post-use comments once I've got the code up and 
running and a model or two framed in my mind.  

Any ideas on lobbying for inclusing in 2.5.x, it's about that time...

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.