Yep. The question *very quickly* becomes, "is func useful enough in
the general case to even bother solving that problem?" Which, I think,
is the *first* question to figure out. Until we know that func is a
viable codebase and something that people will rally to and use,
overdeveloping the security model isn't useful.
Of course, the minute that people decide that func *is* useful, then
the security model becomes *extremely* important, and there's nothing
fundamental to the func design that precludes this work later, AIUI.
Yes. Adding a lot of complexity too soon has killed many a project, and
we are still in the early stages. That kind of thing can definitely be
added later. And it's definitely important :)
* 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.
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 definitely understand the arguments in the "more secure" direction,
I'm sure it will drift there, and it's a good conversation to have --
I'm just worried about the cost
of that kind of system in our goals of being really simple
architecturally and really easy for projects and people to get engaged
with func.
--Michael
