On Thu, 2007-10-11 at 14:10 -0400, Greg DeKoenigsberg wrote: > Some comments inline: [...] > > > * For later versions of freeipa we plan to do machine identity. With > > that you would have a list of machines stored in ldap, groupings of > > those machines, and already have certs / kerberos principals to identify > > those machines. It would also enable you to obtain additional certs / > > principals for the func service securely. > > Should be pretty trivial to just use a different cert. In theory, a cert > is a cert is a cert; if the server can say "hello, do you trust me?" and > the client can say "yes, I'm listening," func doesn't care what that > mechanism is. > You might want to do kerberos instead of certs, though. Kerberos will get you per-user auth easily while the cert model is going to be hard to scale to per-user. > > Speaking of which, it looks like you currently have clients > > automatically obtain certificates from the master server without > > authenticating the master server in any way. This seems like a security > > hole. Basically - if a rogue master server can spoof the master on the > > network (which would be easy) I can intercept registration requests, > > issue a cert, and fully control all of the other systems. It could even > > communicate with the real master and become a man-in-the-middle. > > 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. > > > * 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. Ok - as long as you guys know that you will have to think about security at some point :) I do think moving to separate helper processes early will help you add better security in the future though. Karl
