On Thu, 11 Oct 2007, Karl MacMillan wrote:
I think you are making assumptions about where the complexity will creep
in that are not quite what I meant. If you make 2 changes:
1. run tasks in helper processes
2. have a hook to allow those processes to be run with reduced
privileges (different uid / security context / perhaps privilege set)
based on who invoked the task (probably just user but other things are
possible).
You can add 2 later, but probably the best thing is to allow modules to
be plugged in that figure out the privilege level and start the task.
That way I could write a small selinux module.
With those changes you are pretty much done. The lockdown is *not* done
per-module. That makes no sense with flexible modules that can do almost
anything ssh can do. By separating tasks into processes you can write
selinux policy or use unprivileged user accounts to control what the
tasks are able to do. That makes it an optional, admin task and doesn't
add developer complexity.
You could also add simply whitelist / blacklist style control over which
modules a user can use, but that may not be required.
Hmm. OK, I see the value of this approach.
I don't think it's a good idea to *require* things to be broken out into
helper apps -- and I think keeping the "ssh equivalency" command is pretty
key. But yeah, making it possible to use standalone helpers, and coming
up with basic blacklist/whitelist functionality, could be pretty useful,
pretty fast.
--g
--
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"
