On Thu, 26 Apr 2012 22:08:56 +0200 (CEST) msvob...@linkedin.com wrote: ms> Most exploits / data loss happen from _within_ the organization. If I ms> give a developer / fellow co-worker root access to a machine inside ms> our network, he can snoop around the Cfengine area and see things he ms> really shouldn't be looking at which applies to production machines.
... ms> We dont have to just protect machines that are in a DMZ or external ms> facing.. We have to protect our data from our own users. These two are your fundamental conflict. You want to protect your policies, yet you give people root access. You'll have to split up your policies so only the ones you want are installed on your machines, or perhaps host your policies on a NFS server that doesn't respect each machine's root account. There may be SELinux functionality you could use, but I don't know SELinux well. It's a headache no matter what. <shameless plug>Check out cfsketch at https://github.com/tzz/design-center/tree/master/external_tools/cfsketch which can install policies on individual machines without a central server. You could use cfsketch to install just the sketches you want visible on that machines and to activate them with specific parameters for each machine. cfsketch is just enterting beta, so if you are interested in this functionality, let me know and especially tell me what features you'd like in the tool.</shameless plug> ms> I'd rather have a shared key stored in memory in cf-exced's ms> anonymous area, or some other clever implmementation of encrypting ms> the workspace than not having that option. With the default setup of a Unix system, root can crack all that encryption very easily. It's hard to keep secrets from an account that can access all memory... On Thu, 26 Apr 2012 22:39:26 +0200 (CEST) mikesphar wrote: m> I really do think this is the same problem DRM faces. We're trying to m> come up with a way to allow a device to *automatically* perform m> instructions with no human intervention that someone with the power to m> modify that device cannot somehow intercept. Exactly. The answer is not to protect the device at the edge of the network, but to feed it only the data and policies it needs. That way internal and external security compromises are contained at the edge. I think cfsketch is a good answer to this problem, as I mentioned above. m> I hate to say it but it almost sounds like puppet is better designed m> for this model of "don't tell the client anything that it does not m> need to know", which (if my understanding is correct) puppet achieves m> by performing a lot more work on the server side to compile a policy m> that only applies to each client that connects to it. (I have only the m> barest dabblings with puppet, however.) Frankly if one is that m> concerned with security, it makes more sense to not send sensitive m> data to a client at all if the client doesn't need to know it. Yes, Puppet definitely has a more server-centric model. But a root account on a machine means you can do all sorts of nasty things to the Puppet server, e.g. see the recent DSA 2451-1 (http://lists.debian.org/debian-security-announce/2012/msg00081.html) regarding multiple Puppet vulnerabilities including reading arbitrary files. Root access breaks most security models; very few programs are designed from the ground up with security in mind. CFEngine is very good in this. Dan Bernstein's tinydns, qmail, and daemontools also have very good isolation and containment. Ted _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
