Re: RC separation of duty

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: RC separation of duty
Date: 01 Nov 1999 12:31:00 +0200

Next Article (by Author): Re: RC separation of duty ao@morpork.shnet.org (A. Ott)
Previous Article (by Author): 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]

********* ***************** ********** ****  *****   ***** ************
  To subject Re: RC separation of duty
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

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

This is not restricted to *nix systems. Most commercial systems of all  
types have no such concept. Very many even have an omnipotent admin  
account.

[cut interesting model application sample]

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

To change a user's role you need assign right for both old and new role.  
Otherwise you could e.g. give root a different role, which results in a  
perfect denial of service. So just don't give any of your sub-admins  
assign right to their own role, and they cannot change it. They cannot  
even read their own role settings then...

My concept is to give sub-admins control over role and type subsets. They  
can change everything inside their subsets, but never leave it. Sure the  
different subsets of separate roles can overlap, e.g. the default role 0  
would be contained in several sets to get new users working in different  
areas. Once they are in an area, other sub-admins have no control over  
them anymore.

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

It should work that way.

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

Please give your comments freely.

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

Someone willing to organize a campaign?-)

Amon.

--
Please remove second ao for E-Mail reply - no spam please!
## CrossPoint v3.11 ##
-
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.