Karl MacMillan wrote:
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.
In which case, they are trusting the provisioning server again :)
. 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.
There's nothing saying someone couldn't /manually/ walk the certs around
if they wanted.
Conceptually, I find this totally disinteresting.
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?
VPN. And I would not go to 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.
Walking DVD's around is sneakernet. That's really not a good
solution for anything.
Karl
