[rsbac] To-Do List for 1.2.3

[Amon Ott]

On Monday 29 September 2003 04:34, elvo at virgilio.it wrote:
> i think the better solution to the problem is a an utility to convert ACLs
> from internal representation to path names and vice versa.. and possibly
> an /etc/rsbac-acl.conf file where you can:
> 
> 1) save the internal repr. dump for restore after crashes or everything
> else;
> 2) specify special 'dynamic' ACLs that will be assigned on file/object 
creation
> so you can specify here those files created at runtime with ACLs;
> 
> then it would be necessary to have an utility to 'compile' this file in
> internal repr. and pass the output to a syscall ..

Configuration files are bad for separation of duty - once you can edit these 
files, you can change everything without further control. This is why all 
RSBAC configuration requires fine grained system calls, which are easy to 
control.
 
> another feature could be integration with a filesystem-monitoring patch
> like fam or other things like that to detect an object deletion and restore
> the inode-based permissions assigned to the object..

Same problem: One instance gets full control.

> From: Samuli K?rkk?inen <skarkkai at woods.iki.fi>
> Subject: Re: [rsbac] To-Do List for 1.2.3
> To: RSBAC Discussion and Announcements <rsbac at rsbac.org>
> 
> 
> [huge snip]
> 
> > Hiding the RC type numbers would bring up the issue of what should happen
> > when a RC type is removed. I think the correct solution is that any 
settings
> > depending on the removed object is also removed. So if a FD has RC type
> foo,
> > and that type is removed, the FD gets the default RC type setting.
> 
> 
> when we'll have hierarchies a default setting for every group will be 
possible
> so when you will delete the "xyz engineers files" type the files will get
> the "engineers files" type which will probably be a subset of the system
> permissions .. now with the current RC model state if you have a "web files"
> type and a "samba files" type and you delete one of them the previous 
associated
> objects will get the system default type which is not really god .. in this
> way users are forced to create 'flat' MAC policies for their systems.. in
> conclusion of that i believe hierarchy is one of the most important features
> of modern MAC models (RBAC etc.) ..

Hierarchies can be useful, but they tend to make configurations more 
complicated though another dimension, make the implementation more complex 
and can often be emulated by simple means. So I disagree to your statement 
that hierarchies are so important. In contrary, the flat RC policies are 
intended.

The problem you describe could be solved by changing all assignments of the 
removed type to another one. We can also add a type removal option, which 
automatically performs the transfers all objects of the deleted type to a 
given other type. Type removals should be rare after all.

The default type 0 is an emergency value, which should give only few rights 
to any role. In my setups, access to type 0 is usually read-only.

Coming back to the roles and types hierarchy: This has been requested by 
other users, so it was added to the to-do list, but will be strictly optional.

> i would really appreciate a reply from amon .. excuse for the poor and 
redundant
> english :)

Here it is - and please do not excuse for bad English. Most of us are no 
native speakers, and so far all messages on this list have been fairly 
readable.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22