[rsbac] To-Do List for 1.2.3

[elvo at virgilio.it]

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>

[snips]

> > * Paths versus inodes. There are situations where having things based
on
> > purely inodes just doesn't cut it. One of them is encountered when I
try
> > to limit permissions of fetchmail as much as possible. Fetchmail creates
a
> > file ~/.fetchmail.pid and other than that, only alters the mailbox.
> > Because ~/.fetchmail.pid gets a different inode every time, I can't
use
> > RSBAC to allow fetchmail to create only that file, I must allow fetchmail
> > to create any file in ~. Another case is ~/.Xauthority that gets different
> > inode every time.
>
hi list,

i readed here for some time ..

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

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





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


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


michele