On Mon, Apr 30, 2012 at 11:09 AM, Nick Anderson <n...@cmdln.org> wrote: > On 04/30/2012 09:45 AM, no-re...@cfengine.com wrote: >> No, not at all, because no matter what you do, the local cf-agent >> has to decrypt the policy, and that means it's vulnerable to a >> person with root access. Even if cf-agent only gets the policy, >> decrypts it, applies it, and deletes it 30 milliseconds later, >> the hacker with root privileges can capture that data from memory. >> >> If the client can know it at all, then someone with root access >> on the client can know it. The *only* way to prevent someone on >> a client who has the ability to modify the system itself from >> knowing something is to never send it to the client. > > Well I think if we approach this with the expectation that we will stop > someone with root access from doing anything then we just performing an > exercise in futility.
Yep, and the use of encryption merely shifts the "futility" to a slightly different spot. In order for cfengine to work, automatically, requires that each host that is running cfengine have, close at hand, the decryption key required to decrypt its policy. That means that if someone gets root access to that host, they will correspondingly have access to either that key, or the plaintext cfengine policy, or both. The only way to get around that is to attach a secure crypto appliance to each host, and that *only* solves the "decryption key won't be close at hand" part of the problem, and at a staggering cost. That's the sort of thing that a Certification Authority would do to protect crypto keys on the servers that generate certificates. These crypto appliances are expensive hardware that is time consuming to properly configure. And I thought we were supposed to be using cfengine to *save* ourselves some labour; this seems to head back in the other direction... Note that much of what you're supposed to use cfengine for is to declare *policy* about the configuration of the environment, and a whole lot of that is not at all reasonable to treat as secret. It is very likely that there will be a broad spectrum of configuration and policy that will be not-very-secret, which it is quite reasonable for people throughout the organization to have access to look at. The developers will find it somewhat valuable to get *some* insight as to how production is configured, and how that differs from the "dev" environment, and vice-versa. If there is *some* policy, and rather more likely some data that will be used by some policy, that is sensitive, then to only copy that into production environments is pretty apropos. At any rate, plenty of futility to be found. If you're writing a separate cfengine script for each host, then chances are, it's futile to use cfengine, as You're Doing It Wrong. If you try to encrypt data that will have to *automatically* be decrypted on a whole bunch of servers, then chances are, the encryption is futile, as the keys are readily available on each of those servers. But that certainly doesn't prevent people from trying to do futile things. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
