On 12/22/2011 07:21 PM, Pete Ashdown wrote:
On 12/22/2011 01:01 AM, Mark Burgess wrote:
On 12/21/2011 11:41 PM, Pete Ashdown wrote:
One reason I've objected to the use of puppet in our organization is
the lack of server to client security. That is, if the server is
compromised, then in turn, all the clients are compromised. Before
I start learning cfengine from scratch, I would like to know if and
how this is addressed. Are there any signing of instructions before
they are sent to clients?
Thank you.
Thank you for your response Mark.
Pete, this is a subtle and important issue. Let me try to clarify:
First of all, in any scheme of centralized management, a single point
of control is a single point of failure. This is the nature of the
design. Thus a change on a "server" can always affect every one of
the clients that treat it with authority, no matter what tool you use.
Another way of saying this is that, no matter what your poison, if
you are downstream of a poisoned river, you are also going to be
poisoned.
Signing does not really help in this situation, since an attacker
could also change the signature if he/she can take over the single
point of control. So any system, based on any tools, has this basic
information reality to contend with.
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.
Although I appreciate the encrypted transactions, execution is a much
bigger concern for me than interception on my network. How is trust
restricted? For example, can a node refuse to edit passwd/shadow (or
at least make sure it is static) regardless of what instructions come
down the stream?
Absolutely. Every host has complete control of what it wants to use/reject.
In Puppet, hosts get their view of the world pushed from the "facter"
which runs on the Puppetmaster, according to my understanding, and so
they must trust the central point to a much higher degree. Thus the
poison is sort of poured down their throats without question. This is
because there is some kind of push-me-pull-you thing going on there
with the information. That also means there is a lot of traffic on
the net and a net failure breaks the system.
In the CFEngine architecture, communication is minimized because all
the reasoning happens in a private space of the end host,
guided by the voluntary usage of information from a server, if it is
available. It is fault-tolerant in case the net is not there.
I do like this aspect of the CFEngine architecture. It looks very
resilient and lightweight.
Good luck. and take care.
M
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
