Re: Plans with RSBAC


From: ao@morpork.shnet.org (A. Ott)
Subject: Re: Plans with RSBAC
Date: 08 Oct 1999 11:30:00 +0200

Next Article (by Author): Re: patch for 2.3.19 ao@morpork.shnet.org (A. Ott)
Previous Article (by Author): Maint / non-maint dependency in ACL ao@morpork.shnet.org (A. Ott)
Top of Thread: Plans with RSBAC ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Plans with RSBAC Vadim Kogan
Articles sorted by: [Date] [Author] [Subject]


********* ***************** ********** ****  *****   ***** ************
  To subject Re: Plans with RSBAC
  vadim@scam.XCF.Berkeley.EDU (Vadim Kogan)  wrote:
********** ******************** ******  ********  ******* *************

> On 7 Oct 1999, A. Ott wrote:
>
> > I currently plan to add or change the following (in time order):
> >
> > - Add ACL groups:
>
> Sounds good to me so far. With the only problem that current ACL and
> future rights need to be analyzed for orthogonality (can't come up with a
> better word, but you know what I mean)

Within a single model, all rights are independent from each other. Still,  
you sometimes need several rights for one single syscall to be allowed.

If you are using more than one model, you sure have a kind of redundancy.  
Each model is completely independent from all others, with the only  
exception of AUTH, on which other models have to rely for authorization.

> > - Do we need ACL menu tools, or are the command line tools sufficient?
>
> Yes, we do. And I hope I'll have time to help with those. In order for
> RSBAC-based distribution to be helpful, it should be manageable. It should
> be admin-friendly, and while admins are comfortable with ls/rm/cp/etc,
> RSBAC roles/ACLs/etc are much more complex and overlap, so more intuitive
> representation is needed.

I already thought so, but I hoped not to have to do the fuzzy menu things.  
But the tools are designed to support scripting, so the tools won't be  
that difficult.

As a kind of goal for 1.0.9a (or 1.0.10, if there are urgent bigfixes):
- minor bugfixes (like dependencies, module loading with ACL)
- ACL groups (already in progress)
- menu tools (well, must be done)

Vadim, you need a complete understanding of the current state of ACL when  
programming the menues, and the menues sometimes need changes in command  
line tools. So you cannot help me there, but I really need help with  
testing as soon as I push out a 1.0.9a-pre1 - like with all pre's.

The mentioned bugs in a final release annoyed me quite much, specially  
after so much time since the last one.

> Socket stuff I'll need to think more about after sockets are persistent.
> At least for me, the scheme of using them will emerge from needs of
> distribution (that also will hopefully make sure that we don't add
> unneeded rights).

The changes aim at some kind of distributed RSBAC in our networked world  
and will take a lot of time.

> Couple of other things that I'd like to mention (low priority probably):
>
> role-setting daemon (not 100% sure it's needed though, need to analyze
> more)

You are welcome to add one... ;)

> secure truncate (i.e. a variation on what we have now, but really secure.
> Should not replace current code, but rather add another feature).

Like triple overwrite with patterns?

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.

Next Article (by Author): Re: patch for 2.3.19 ao@morpork.shnet.org (A. Ott)
Previous Article (by Author): Maint / non-maint dependency in ACL ao@morpork.shnet.org (A. Ott)
Top of Thread: Plans with RSBAC ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: Plans with RSBAC Vadim Kogan
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.