Re: Plans with RSBAC

From: ao@morpork.shnet.org (A. Ott)
Subject: Re: Plans with RSBAC
Date: 18 Oct 1999 10:50:00 +0200

Next Article (by Subject): Re: Plans with RSBAC "Paul D. Robertson"
Previous Article (by Subject): 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 "Paul D. Robertson"
Articles sorted by: [Date] [Author] [Subject]

********* ***************** ********** ****  *****   ***** ************
  To subject Re: Plans with RSBAC
  proberts@clark.net (Paul D. Robertson)  wrote:
********** ******************** ******  ********  ******* *************

> On 7 Oct 1999, A. Ott wrote:
>
> > Hi all!
> >
> > I'd like to discuss my current RSBAC wishlist with interested people like
> > you. Please give comments and new wishes, if you need something else -
> > this is another planning phase to keep me busy for a while... ;)
>
> I've been thinking about a few things, but I'm not sure how much is
> "haven't played around enough..." and how much is "Hmmm, this is kind of a
> neat idea, but not ultimately useful."
>
> First with MAC (and I'm currently building another test system, so point
> me to TFM if appropriate) is there a way to set a system default value so
> that any user that isn't assigned to a MAC category can't run anything
> (or indeed log on), until they're added to the "lowest MAC necessary to
> log on?"  This would be so that I could set SYSTEM_MAC to say "secret",
> and then add a user, set the login process and maybe /bin/sh to
> "unclassified", and add the user to "unclassified" and they'd only be
> able to run what was specificly downgraded to that MAC?  A user added to
> "secret" would be able to run anything that wasn't specificly upgraded to
> "top secret", etc.  Is this already a feature, or am I hoping (I tend to
> think in MAC compartment units, but roles would be useful this way too)

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.

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.

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

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.

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.