[rsbac] To-Do List for 1.2.3

Sun Sep 28 09:19:14 MEST 2003

On Fri, Sep 26, 2003 at 03:51:00PM +0200, Amon Ott wrote:
> On Thursday 25 September 2003 17:40, Samuli Kärkkäinen wrote:
> > On Thu, Sep 25, 2003 at 12:48:26PM +0200, Amon Ott wrote:
> > > this is my current to-do list for 1.2.3. Please add your wishes now. 
> > 
> > * Show executing process' RC role in the log output. I keep missing this
> >   when trying to figure out why things are working the way they are. As the
> >   log output has a lot of fields already, maybe it should be configurable.
> 
> Please try the debug_adf_rc switch, it gives you both role and type for 
> denied requests in an extra line.

I'm sure I'm missing something obvious, but where should I see these lines?
I'm not getting anything new into syslog at least after I did "echo
debug_adf_rc 1 >/proc/rsbac-info/debug".

> > * With "request CREATE" operations, the log output apparently doesn't show
> >   which directory is being created, but instead what directory it is being
> >   created _in_. It would be more informative if it reported the former.
> 
> Since RSBAC is inode, not name oriented, the new target id is yet to be 
> created. I can give you the requested object name in the log, if you want.

If object name means the path of the directory to be created, then yes, that
would be good.

> > * Have it possible to set JAIL for executables in the menus the same way RC
> >   types are assigned. It'd be nicer if all RSBAC related things were done
> >   through menus, instead of having to hack rsbac_jail commands into startup
> >   scripts of things. Hacking the startup scripts is a sure way to cause
> >   nasty surprises when one updates the distribution and half a year later
> >   realizes the JAILs haven't been in effect ever since the upgrade.
> 
> The idea of the jail module is that you need *not* administrate anything - 
> just change the way you start the program and be happy.

The way I see it is that the amount of initial work is about the same
regardless of one needs to change the startup script or to use rsbac fd menu
to have a program start in a jail. With the former approach the JAIL
configuration works the same way as other rsbac things, is backed up and
restored the same way etc, and is hence easier to remember to check, I
think.

> > * If you remove an RC type, then in the FD menu, you can't assign another
> >   type for a file that has the type that was just removed.
> 
> Cannot verify this, works here.

Neither can I, now. I guess my notes were inaccureate. Maybe I'll hit the
problem again some day.

> >   Yet another way would be to combine RC and ACL modedules with "or" instead
> >   of "and", that is, access would be allowed if either of the modules allows
> >   access.  Of course it wouldn't make much sense to extend this logic to say
> >   the JAIL module, so this seems like a pretty bad idea, but it sure would
> >   be a simple way to greatly add the power of the RSBAC framework if it
> >   could be done cleanly.
> 
> Configurable metapolicies like "(ACL or RC) and JAIL" have been thought about 
> and abandoned so far, because anything not restrictive makes models dependent 
> on each other. Any mistake in administration of one model would also affect 
> the security and integrity of the other.
> 
> So, it could be an option, but would be off (maybe even discouraged) by 
> default.

I have been thinking about this, and it's starting to seem like a fair idea.
It's not obvious to me that the chances of creating an insecure setup is the
lowest if the modules are ANDed.

I think the crucial step in creating a good, secure and maintainable rsbac
configuration is to be able to clearly understand how the modules are to
work and interact in the configuration. If one, due to limitations of rsbac,
is forced to come up with a convoluted, unnatural way of using the modules,
I believe that will result in a setup that is quite likely to have security
compromising errors, because the setup will be hard to understand. In other
words, my argument is that if the metapolicy idea makes it possible to
create a configuration that is easier to understand than without the
metapolicy would be possible, that is likely to increase the security in
practice.

Also while at first it seemed stupid to have a "ACL or JAIL" metapolicy, it
no longer seems that way. Maybe someone wants to basically just use JAILs,
but wants to allow some operations not allowed by a JAIL. This would almost
certainly be easy to do with a simple "SOMETHING or JAIL" metapolicy, but
perhaps impossible without metapolicies.

This idea of the importance of interaction between components of a system is
well explained in http://www.namesys.com/content_table.html#1_1. The one
line summary is "Total system utility tends to be proportional not to the
number of components, but to the number of possible component interactions."
I have come to believe security system is one of the places where this idea
applies. Also, metapolicies could well help to avoid creeping featurism in
individual modules, as the "ACL or JAIL" example above exemplifies.

Anyway, it's always easier to come up with reasons for adding new features
than to understand the subtle harm done by accumulation of them. Do you have
examples of how the metapolicy system could lead in bad situations?

> > * 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?
> - Are access rights supposed to change when the file gets renamed (or a new 
> name created and the old deleted)?
> 
> Peter also gave the speed argument, but, while correct, that was not my point.
>  
> >   In fact, I'm not sure why RSBAC isn't entirely path based instead of inode
> >   based. I believe there are good reasons for that? And even if it's
> >   necessary operate on inodes on the lowest level, storing the settings on
> >   path basis on UI level (and I include command line utilities in the UI
> >   here) would make backup and restore vastly easier and more robust than
> >   currently, which I personally consider a major problem at the moment.
> 
> There is no direct way from inode number to path. Configuration must be 
> stored in the kernel to allow enforcement of separation of duty. And 
> filesystem objects can only be uniquely identified through inode numbers.
> 
> All this means that stored configuration should only use paths and userland 
> files for emergencies, e.g. restore after a system crash.
>  
> > * Related to above: if I add create permission to ~, all subdirs inherit
> 
> This depends on the model involved, but is correct for most of them.
> 
> >   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.
> 
> 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.
> 
> In many cases, it is possible to create and use sensible structures under ~. 
> If some program insists on creating a subdir or file in ~, give it CREATE and 
> SEARCH to this dir, but use an RC default_fd_create_type which gives the 
> program the rights it really needs. Most programs can be fooled, if you have 
> a prepared dir in /etc/skel and set types during user account creation.
>  
> > Finally a couple of questions:
> > 
> > * What is the idea of the Auditor role?
> 
> This predefined role may read the RSBAC logging source like the security 
> officer, but may not administrate anything. Thus, an independent auditor can 
> check the system with limited rights.
>  
> > * 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
> This means that someuser's default role, not the role issuing the command, 
> must be compatible with the target role. (Or, please hit me now, you can set 
> an initial role on rc_role_wrap and restrict its usage).
>  
> > Lastly, despite all the problems mentioned above, I think RSBAC is by far
> > the best security addition to Linux I've come across, and I believe I've
> > seen vast majority of them. Wonderful work, Amon.
> 
> Thanks a lot. :)
> 
> Amon (who has once more entered #rsbac channel at irc.debian.org, in case you 
> are interested in a chat).
> -- 
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

Why are type numbers used? There can't be a type without a name anyway,
so why should I care what number a type gets?

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