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
