Re: RC separation of duty

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: RC separation of duty
Date: 05 Nov 1999 10:54:00 +0100

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

********* ***************** ********** ****  *****   ***** ************
  To subject Re: RC separation of duty
  vadim@scam.XCF.Berkeley.EDU (Vadim Kogan)  wrote:
********** ******************** ******  ********  ******* *************

> On 1 Nov 1999, A. Ott wrote:
>
> > 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.
>
> NW4+.

I know NW4 is different here, but it still cannot filter out Supervisor  
right inside a volume, only in container hierarchy.

> > 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.
>
> I think you're limiting yourself to roles, while you also have a nice ACL
> with inheritance AND blocking mechanism. Think about how it's done in
> NW4+.

Well, there is a reason why I called this thread RC separation of duty. It  
is about RC only. :)

ACL model already has a wide separation of admin duty regarding object  
rights settings.

> In fact, in NW way things can go even funnier - you can have a container
> with its own admin, in which there is a user who is NOT an admin in that
> container, but IS admin in some other container (possibly even on higher
> level).
>
> Now, here's something that was discussed here before, but is not available
> in NW: being able to have "50% admin" permissions to some container and
> combine that with another "50% admin" permissions owned by another user
> and get access to admin the container (and, unless there is blocking
> involved, all objects in that container/subcontainers).

We would have to introduce some ticket/token scheme here, which is not  
that difficult to do. And several threshholds, like "you need n different  
admins giving the same command to make it work". You see it with n=2 in PM  
model tickets.

Please note that such a system requires a huge amount of extra design and  
coding work, which means it won't be there soon.

> There is another plus in such "container" structure. It makes it easier to
> present structure to user. I know you gonna scream that it's lame, but it
> is really important to be able to have good UI.

I think the NDS was a brilliant idea. I only don't want to implement it  
myself. Remember how many years it took a big Novell team to get it stable  
enough for real work.

> I should also say that groups/roles are opposite of containers in most
> part. Group is made to give many objects same control over something.
> Containers can be used to give one object control over multiple objects.
> That is groups are many-to-one and containers are one-to-many. Obviosly
> either one can be extended to give both possibilities.

Everything granted, and everything useful. But possibly beyond our means.

> Unlike NW, we have a special container with subcontainers that is called
> "kernel" - it got ttys, ports, devices, etc, etc, etc.

We also got the ACL default settings, which already are like a single  
container per object type.

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.