On Thu, 2007-10-11 at 14:23 -0400, Michael DeHaan wrote: [...] > > > > >> * Another security concern - is the funcd on the clients trusted to > >> perform all of the actions? This will make it a huge target for attacks. > >> Could you instead exec helper applications? This would also allow you to > >> run the helper applications with lower privileges - either in an > >> specific selinux context, have it drop some capabilities before exec of > >> the script, or even as an unprivileged user. > > > > Again: first let's validate that people find func (a) useful and (b) > > something they would want to extend with a community of modules. > > *Then* worry about things like "helper scripts with dropped privs." I > > think everyone's pretty well aware that, to start, func is nothing but > > a big ol' rootkit. *For now*, that's perfectly okay. > > > > Fundamentally, anything that is remotely useful for systems control and > management in this broad sort of way needs to have magic powers to be > able to do what > it needs to do. So, as long as we have an uber-module (like command.py), > having less restricted modules is kind of pointless. > > One problem (not saying it's unsolveable) with splitting out things into > helper apps is that you lose the ability of your program to do native > exception handling (tracebacks all the way down) and you can't exchange > variables without extra serialization. This complicates things and gets > all enterprisey really fast. Again, I'm not saying we couldn't do it, > but it smells of "big architecture" and I think we need to crush that > impulse until we start to see how the community wants to use the > project. Simplicity drives adoption and keeps developers happy. > Yeah, security and error reporting are often at odds unfortunately. > The aforementioned SSH equivalency command module, which is pretty much > required to make func usable around non-Python coders, needs to be able > to do, arbitrary, > whatever it needs to do. > > While we aren't a configuration management system, the same is true of > things like cfengine that need to modify the system arbitrarily. > > I think concentrating on the way we manage certs is fine, but the > privelege level stuff needs to come from user demand from a community > perspective, before we create > something too complicated to develop for. > > My two cents on the simplicity goal, anyway... > 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. Karl
