[rsbac] To-Do List for 1.2.3

[Samuli Kärkkäinen]

Sorry about the previous mail. I sent it prematurely. In particular sorry
about the last couple of lines about RC type numbers - they were notes meant
for my consumption only :)

> > * 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.
> 
> There are many such cases. However, the only one-to-one identification is the 
> inode number.
> 
> - There may be multiple names for a single file. Should there be different 
> rights depending on the name you actually use?

I'm not certain which behaviour would be preferable. It's easy to think of
arguments in favor of both choices. Ofcourse Unix has traditionally been
inode based when it comes to permissions, but I don't know if that is a
major consideration.

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

So all I'm left with are my earlier arguments that are much in favor of path
based system. That w save you from adding the --exclude option to the backup
scripts too :)

> >   that. Home directories tend to have a huge and volatile number of
> >   subdirectories, so it's not feasible to try and enforce permission
> >   inheritance of them all.  What I want in this case, is to say "skip ~ in
> >   permission inheritance" or "replace ~'s permissions with the defaults in
> >   inheritance" or something like that. AFAICT, this is not possible?
> 
> I am not sure I understand you correctly. The inheritance code has no idea of 
> what ~ is, so we would need some flag 'skip this dir'. It would make the 
> setup much harder to oversee.

Yes, a "skip this dir" flag is probably what I was basically suggesting. To
make sure we're talking about the same thing, my idea is as following.
Firstly, I used ~ only as an example of some directory. The ~/.Xauthority
file is something that is accessed by all X programs (I want to limit rights
of certain X programs that access network, such as X-Chat). Also
~/.Xauthority gets recreated upon every login. AFAIK it's not an option to
either disallow access to it or move it elsewhere. So in order to let X
programs access ~/.Xauthority, I must give them at least read rights to ~,
probably also the CREATE right.

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. Let's say rsbac starts
determining RC type of ~/foo, which has type "inherit parent dir". So rsbac
looks at type of ~ and notices it has the flag "skip inheritance", so rsbac
ignores the RC type of ~ and moves on to looking at RC type of parent dir of
~.

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.

Setting permissions of every suddir of ~ is not one of the feasible
solutions, as the number of those directories is vast and constantly
changing.

> On all my systems, home directories are rather small in size, and masses of 
> data are stored in common repositories with a multi-level directory structure.

I can see that being a common situation. I take it you haven't tried
securing your desktop environment with rsbac :)

> > * I'd like to do something like "rc_role_wrap 7 su -l someuser". Now this
> >   doesn't work since apparently the root user to which su changes gets the
> >   role 7 and the someuser ends up getting whatever but not role 7. How
> >   should one do this?
> 
> The other way round:
> sudo -u someuser rc_role_wrap 7 /bin/bash -login

Yes, that works. Thanks.

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.

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.

-- 
  Samuli Kärkkäinen                   |\      _,,,---,,_
 skarkkai at woods.iki.fi ---------ZZZzz /,`.-'`'    -.  ;-;;,_------
http://www.woods.iki.fi              |,4-  ) )-,_. ,\ (  `'-'
                                     '---''(_/--'  `-'\_)