Karl MacMillan wrote:
On Thu, 2007-10-11 at 14:55 -0400, Greg DeKoenigsberg wrote:
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
You could certainly allow them to be run either in-process or
out-of-process. The downsides are that there may be subtle bugs in one
and not the other and you miss out on some robustness that you get from
the separate processes.
-- and I think keeping the "ssh equivalency" command is pretty
key.
Sure - and by using the separate processes you can have that *and*
enforce some meaningful restrictions on it in a flexible way.
But yeah, making it possible to use standalone helpers, and coming
up with basic blacklist/whitelist functionality, could be pretty useful,
pretty fast.
Obviously I agree.
Karl
Karl -- #func on freenode.
