[rsbac] To-Do List for 1.2.3

[Peter Busser]

Hi!

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

> But I don't want to give X programs any rights to any subdirs of ~. Hence, I
> don't want subdirs of ~ to inherit its rights.

You mean that if you start a web-browser, you cannot even save files to your
home directory? Or you cannot access the home directory when you start a
virtual shell?

> Now I agree that the "skip inheritance" flag would make the system much more
> complex. That's bad. At the same time, in absence of path based permission
> system, I can't come up with any feasible solution for the ~/.Xauthority
> problem.

You can simply skip the inheritance by setting the attribute to the value you
want.

> And about the RC type numbers - I'm thinking they are much too visible. 
> When I create an RC type, I'm really not interested in what number it's
> going to get. Same goes for RC role numbers ofcourse, maybe also to some
> other such rsbac numbers.

That is also something that I put in the RSBAC policy support tool. You specify
RC roles, types and rights by name and the tool deals with all the numbering
stuff.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/