On Tue, 2007-10-16 at 10:36 -0400, Michael DeHaan wrote: > Apparently my last reply was off-list, so here it is...it's basically > what Seth said, though I wrote it without reading his. Seth keyed in > on a couple of different points too. > > [snip] > > Any datacenter distribution system leaves some room for basic MITM at > provisioning time because there is a need for automation. The tradeoffs > [in func's implementation] are minimal. Admins know this. > Sneakernet and highly manual/fiddly solutions are right out. For > instance, it would be possible to MITM a kickstart server. Oh no! You > could install anything! Exactly. [More simply: Your machine is an > unintelligent piece of metal and has to trust something]. > Many organizations provision on separate, trusted networks for this reason. > I am assuming the case you are actually worried about is a func minion > registering itself to the wrong master yes > . This worry is not significant > due to the aforementioned greater concerns -- if you have MITM problems, > you can have problems at even earlier in the provisioning cycle. I understand that for some people, in some circumstances the risk is acceptable. That's fine. However, not having any mechanism for secure distribution if it is needed doesn't seem like a good idea. > > Func's system (which is what puppet does, only more generically so), > strikes a good balance of making things actually usable, and in > datacenter provisioning cases is NOT a major security risk -- admins are > aware of the tradeoffs. If you have MITM capability within your > datacenter, lots more damage could be done. You have greater > problems. Trust is required at provisioning time to achieve > automation. [Non-automated provisioning setups for large > datacenters/clusters are a non-starter]. > Inherit in what you say is making a tradeoff for the usage that you currently see. But what about other usage? What if you start using this for desktops / laptops that are not in a protected data center network? What if you need to get keys to laptops sitting on a wireless network at starbucks? Doesn't it make sense to allow for a more secure key distribution for different usage scenarios and let the _admins_ make the trade-off? For example, if an organization has already invested in a kerberos infrastructure you can bootstrap your key distribution off of that in an automated way. Or you could leverage ssh as the channel for the initial key distribution. Or signed packages. There are many mechanisms for mutual authentication - all you have to do is allow the possibility for using one or more of them rather than only offering a known insecure mechanism as the _only_ way. > This is supremely better than, say, trading SSH keys in kickstart files > -- which many folks want to do already. That in itself is inherrently > insecure because of Anaconda's inability to do auth and https://. > Again, the provisioning automation scenario reigns. > Depends on how they do the kickstart. Using custom DVDs or a separate lan for provisioning can make this secure. Karl
