On Fri, 2007-10-12 at 11:19 -0400, seth vidal wrote: > On Fri, 2007-10-12 at 11:05 -0400, Karl MacMillan wrote: > > > 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. > > the maintenance and care of kerberos servers makes everything a mess, > not to mention integrating these with most common applications. The > ticket expirations, the mucking about with 3rd party apps to make them > work. It's just a world of fun. We went down this path with urlgrabber a > while back and the answer was 'ugh, no, stop, run away'. > Take a look at freeipa.org - we're trying to fix many of those headaches. I agree that kerberos administration has been _very_ painful, but I think that the underlying technology is good and has the potential to make things better. > > > > 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. > > actually, that's not true. Many MANAGERS want to centralize their > identity. Most admins want to keep hosts and users as VERY different > concepts. > > Managers want it b/c they think it means they can cut down head count > b/c they'll have fewer pieces to manage. > Again - different experiences. > > > 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. > > And in the whole scenario you have to get bits onto the minion that you > trust somehow. Your options are: put them in a pkg and trust that the > deployment server is not compromised or spoofed. Which is the same as > the what you're describing above. > Not at all - package signing will take care of the problems that I've described. > so we've not won anything. We have to have an entry point of trust. > We've chosen ours at the same place puppet chose theirs. > Then puppet is making a mistake too. There are plenty of ways to do mutual authentication - just pick any one of them. > > That does not agree at all with my experience (and I have worked as a > > sysadmin). > > For how long did you work as a sysadmin and for what kind of systems? I > was an admin for both small, medium and large scale infrastructure. In > all cases if setting up the infrastructure meant bringing up anything > larger than a single process then you had to go into a meeting to > determine if you could do it. meetings are death. So in most cases you > just avoided anything that required infrastructure. > > You'll notice that people love setting up yum repos on an already > existing http server b/c they're no-infrastructure required. But setting > up RHN requires an act of congress and makes most people want to shoot > themselves. > > There's a reason for that. > We can debate our sysadmin cred, but honestly I'd rather not. If you really think that your experience translates to the entire world then so be it. > > > > 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? > > no more than the danger present by ssh and ssh keys. Again, we've just > taken on 'the danger' that another tool has - we've just made it more > realistic for sysadmins to use. > Well - you may present more danger because you have deliberately weakened the authentication mechanism. However - I think the ssh analogy is mostly right. And the openssh guys did exactly the type of privilege separation I'm suggesting because they understood the risk. > > 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. > > We're not making the network any more vulnerable than ssh, puppet, rhn > or cfengine make it. And those are all recommended solutions. > Not true - take puppet for example. In their recommended configuration they don't have a client daemon listening because they understand the danger of having a root process listening for arbitrary commands from the network. Karl
