[rsbac] To-Do List for 1.2.3

[Amon Ott]

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

This is a bit tricky, but possible. We would need some file attributes for 
the executable. The problem is the chroot dir, which could be on another 
filesystem. Without it, ok.

If you use the -v flag to rsbac_jail and check your startup log from time to 
time, you should notice missing messages.

The idea of the jail module is that you need *not* administrate anything - 
just change the way you start the program and be happy.
 
> * For the exclude option for the backup scripts, maybe make it a shell style
>   glob against canonicalized path name. This would allow things like
>   --exclude /home/*/Maildir/* (which, on purpose, would also be different
>   from home/*/Maildir that would exclude also the directory entry in
>   addition to the directory contents). Or why not a regexp once you're at
>   it.

Well, yes, a lot of work to implement, but feasible. For now, you will have 
to stick to a find | xargs script based on backup_all.
 
> * Why is the rsbac_jail utility root only? It only reduces permissions,
>   doesn't add them, so I don't immediately see how non-root can endanger the
>   system by using it.

Right, removed the check for 1.2.3. I may have thought that normal users 
could misuse it. The attached patch against jail_syscalls.c disables the 
check for 1.2.2, too.
 
> UI stuff:
> 
> * In the help output when you run rc_role_wrap without arguments replace
>   s/new_role/new_role_number/. It confused me at first why things appear to
>   not be working as I tried to enter the role name instead of the number,
>   since the utility didn't even give any error message of non-existing role.

Done.
 
> * When you run rsbac_rc_role_menu the title is "Startup: Choose initial
>   role". I remember at first finding this confusing, as I wondered if it
>   asks me choose default role for processes or something. A better title
>   could be "Choose a role to edit".

Changed.
 
>   Also, in that menu if you press the Cancel button you get into the RC Role
>   main menu with nothing selected.  This is a UI state which makes no sense
>   and hence would be better off not existing. Similar situations where a
>   menu is in state where nothing is selected probably exist elsewhere.

It does make sense in case you want to create a new role. I default the role 
to 0 now.
 
> * In the FD menu, it seems that when one is in the "Attribute Get Mode:
>   effective" state and changes fe. RC Type FD, the UI behaves as if the
>   change takes effect, but it doesn't. Probably changing the values should
>   be prohibited altogether in that state.

AFAIK, they do take effect, but I agree that they should not. Just added a 
check with a message to all attribute selections.
 
> * 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.
 
> Some long term things:
> 
> * Overlapping file sets in RC types. Okay, this is something that has been
>   asked before, and there are many ways to implement what I want, and all of
>   them are controversial. My goal is still the same as in my first email a
>   few weeks ago: I have defined a bunch of types for files and a bunch of
>   roles. Now I add a new role, which typically wants access to a few more
>   files than some of the existing roles. It'd be nice to just define a new
>   type for those files and give the new role suitable access to that type,
>   without having to worry about what permissions to give to that type for
>   the other roles.

Multiple roles and types for users, programs or objects will not happen. My 
first reason is:
 
>   Of course, if a file could have multiple types, one should come up with 
the
>   logic for what happens if one type doesn't allow access and another does
>   allow. For my purposes it would be useful, if the default is that no
>   access is allowed, and access is allowed if any type allows access.

Multiple roles and types make it very difficult to find the effective rights 
of a subject to an object, and designing these roles and types is a 
nightmare. So for ease of use, there will always be one role and one type at 
a time.
 
>   Another, and almost certainly better way to implement what I want would be
>   to create concept of "file sets", and assign ACL entries for the file sets
>   of instead of individual files. I haven't thought of this deeply, but it
>   would seem to me that this wouldn't require big changes to the ACL module
>   logic. This would be somewhat redundant when you have the RC type concept
>   already, although it wouldn't make sense to assign for example RC
>   force/initial roles or the symlink settings for file groups. I haven't
>   looked at this, but I imagine many other modules could be willing to refer
>   to the file sets instead of individual files, too.

We could easily add ACLs for RC types, which would only be used in ACL model. 
However, this raises the following well known question again:
 
>   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.
 
> * 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
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde geschreddert...
Dateiname   : jail_user.diff
Dateityp    : text/x-diff
Dateigr??e  : 489 bytes
Beschreibung: nicht verf?gbar
URL         : http://gateway.compuniverse.de/pipermail/rsbac/attachments/20030926/b75f966f/jail_user.bin