On Fri, 2007-10-12 at 10:16 -0400, seth vidal wrote: > On Thu, 2007-10-11 at 13:19 -0400, Karl MacMillan wrote: > > So func looks interesting and I wanted to ask a few questions about > > potential integration w/ LDAP and kerberos (and freeipa.org). > > > > * Any chance you would be interested in supporting kerberos in addition > > to certificates? The main advantage here is that you would be able to > > authenticate specific users or services on other systems more easily. > > kerberos is pain and death to every project I've ever worked on. The > moment it is added the requirements explode and the application becomes > a 'special case'. > Why? I'd be interested in some more detail. > > > * 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. > > again - only by having a massive infrastructure setup. One of the design > goals of func was to NOT require any special infrastructure or > architecture. > But why prevent it working if you have that infrastructure? Many shops want to centralize their identity - both machine and user - so working with central identity seems like a huge win. > > > 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. > > > > If a rogue master can spoof the master on the network then your network > has very much other problems. Not particularly - it is very easy to do this type of spoofing and preventing it is just good protocol design. > More to the point: If I'm setting up a box and I go to the certmaster > and there's no csr there waiting for me to sign it, then I will look > into it further. Doing otherwise is just being a bad sysadmin. > Per my man-in-the-middle scenario, everything may look perfectly normal to the sysadmin. > > > * 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. > > it runs as root and it needs to run as root - in much the same way > puppet or cfengine or cron does. This is a tool for sysadmins to help > maintain large sets of systems. sysadmins need to be able to operate as > root w/o having to jump through hoops. They do anyway. > > I don't have a problem with making things better, I do have a problem > with adding complications that, ultimately, most sysadmins will never > touch b/c they don't need them. That does not agree at all with my experience (and I have worked as a sysadmin). I think the ability to delegate a portion of administrative authority is very beneficial, especially if you consider using func as a building block for higher-level management software. You've never wanted to give the ability to do backups/restores, updates, reboots, whatever to an office manager? Do you really want to give them root on every system controlled by func to do that? Look - sudo is popular for a reason and it seems natural and simple to give func some similar features. More importantly, however, is the ability to control malicious software. Even if the total authority granted to the admin is equivalent to root, running each component with less privilege will prevent a small error / exploit from becoming a complete compromise of every system controlled by func. Do you really not see the danger you are creating here? I understand the convenience and usability goals, but no one will thank you for creating the perfect platform for the total compromise of their entire network. Karl
