On Thursday 22 Dec 2011 20:51:51 Christopher Browne wrote: > On Thu, Dec 22, 2011 at 2:20 PM, Mark Burgess <mark at cfengine.com> wrote: > > I like your analogy of the poisoned stream.? :-)? However, taking over a > > properly maintained signature is a much smaller vector than gaining > > access to the headwaters (especially if you have several people manning > > the pumps).? If the signing private key is password protected itself and > > kept off the server except for changes, then the attacker has no control > > over the clients that respect the key.? I would presume that this is why > > package repositories and software distribution/update systems have been > > so successful at keeping their rivers pure.? I am disappointed that you > > view it differently. > ... > > The difference between Puppet and CFEngine is who owns the information on > > which decisions are made. In CFEngine, nodes are basically autonomous and > > each node controls its own information and its own decisions, based on > > its private view of the environment. The nodes can pull down > > data/information from a server (choose to drink from the poison), but > > they are under no obligation to trust it or use it. There is strong > > (crypto) authentication (ssh style) that maximizes the likelihood of > > authenticity, but ultimately if upstream is poison, a node cannot really > > tell. > > That latter bit is the "poisonous" part... > > CFEngine may make the nodes more autonomous, in principle, but if the > policy feeds from the possibly-poisoned source, that poisons > destinations. > > And if the upstream has been poisoned, the downstream can only "tell" > if the downstream portions have some independent intelligence. In > effect, they would need to have local policy that *isn't* fed from > upstream. And that implies you need to have some additional way to > get the local/downstream policy updated. That seems like a recursive > problem to me, mostly amounting to giving up on centralizing policy > management. > > > Absolutely. Every host has complete control of what it wants to > > use/reject. > > But for that statement to be true, you need to have some separate > policy on the host to evaluate what upstream material it will > use/reject. Theoretically plausible, but needing generous doses of > unobtanium, as far as I can see.
Hi, new to cfengine, so correct me if I'm talking nonsense. Aren't updates on managed hosts explicitly implemented in policy (e.g. the update.cf samples, etc.) by copying data off central host? In that case you only need to add a level of indirection, e.g. copy from central host to masterfiles (instead of to inputs/ directly), run signature verification, and only then replace the live policy in inputs/. Would that not work? Another option which I'm considering now is to let managed nodes pull from VCS directly into their own masterfiles and change policy in update.cf to just copy locally into inputs/ modules/ etc. after doing some local processing/verification. Any disadvantages? -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify supp...@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
