[rsbac] To-Do List for 1.2.3

Amon Ott ott at compuniverse.de
Sun Sep 28 01:15:04 MEST 2003


(I do not have the original message here)

On Sonntag, 28. September 2003 19:17 quoth Samuli Kärkkäinen:
> On Sun, Sep 28, 2003 at 06:53:17PM +0200, Peter Busser wrote:
> > > > - Are access rights supposed to change when the file gets renamed (or
> > > > a new name created and the old deleted)?
> > >
> > > Right now I see the problems caused by software upgrades important, and
> > > from that point of view, it's best if permissions depend on path, not
> > > inode. Other than that aspect, again neither path nor inode based
> > > approach seems clearly superior.
> >
> > Well, you don't have to solve every little problem in the kernel code. If
> > you want to set permissions based on a path, then you can write a utility
> > that will do that for you.
> >
> > I did that for instance with the RSBAC policy support tool, which is part
> > of Adamantix unstable.
>
> This is indeed one way to solve this issue. However if rsbac really were
> path based it would also solve the "~/.Xauthority problem" and remove the
> necessity of "restoring" all permissions after any rpm/deb update. It just
> seems to me the path based approach would be cleaner, but it's also
> possible the better solution is to have good user space utilities.

Path based control means dealing with strings instead of numbers, and it needs 
a conflict scheme to deal with multiple names for a single file and renames. 
The inode number has been chosen to have guaranteed unique file 
identifications, and I do not want to change to paths.

The backup issue is did not occur as such a problem to me, because I have been 
using it with success for years. However, we can add a few measures to speed 
them up significantly. I already have an idea to use reference counters for 
dirs, how many subdirs or files have attributes below them. If ref count is 
0, we can skip the whole sub tree.

> If rsbac becoming internally path based allowed simpler user space
> utilities but wouldn't make rsbac more complex (other than probably
> neglible performance cost), that wouldn't seem like such a bad ide to me.

It would make RSBAC more complex and, in my way of thinking, less reliable. I 
specially dislike the idea that renaming a file changes the rights to it, 
although the content to be protected remains unchanged.

> I can certainly see that change being a lot of work though, so it may just
> not be worth it. But I'm presenting ideas and letting Amon and maybe others
> familiar with internals of rsbac consider their feasibility.

The work would sure be another problem, and it would need a complete change in 
the way of thinking about RSBAC access control setups.

BTW, if path based access control requires to store setups in edited 
configuration files, it would significantly decrease the security in 
administration - config files prevent kernel based separation of duty. Even 
Peter's description files can only be changed and used in a controlled way.

I agree that the current scheme to make a backup, update a package and restore 
the backup is not the best of ways. We will have to improve on this, but it 
requires some knowledge about the packages.

Amon.



More information about the rsbac mailing list