[rsbac] To-Do List for 1.2.3

Thu Sep 25 19:40:48 MEST 2003

On Thu, Sep 25, 2003 at 12:48:26PM +0200, Amon Ott wrote:
> Hi folks,
> 
> 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.

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

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

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

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

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.

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

  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.

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

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

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.

  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.

  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.

  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.

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

  The only solution I can think of is to maintain a list of path names and
  match against them on every access. How the UI would handle that, I have
  no idea.

  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.

* Related to above: if I add create permission to ~, all subdirs inherit
  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?

Finally a couple of questions:

* What is the idea of the Auditor role?

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

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.

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