On Mon, Sep 13, 2010 at 07:32:55PM +0200, Eystein Måløy Stenberg wrote: > First off, Cfengine 3.1.0 due for October will have new functionality > for recognizing hosts. It uses the hash of the other party's public key > rather than the IP/DNS-address. Thus a host will be recognised even when > changing IP/DNS addresses.
Nice! This is exactly what I suggested in earlier mail and suits my use case very well. > Secondly, the well known key distribution/trust issue is not possible to > solve automatically without some external trusted channel. This is not a > limitation of Cfengine. Thus, you ideally should exchange keys manually > over some secure channel. What Cfengine allows is to assume trust from > IP/DNS ranges, which is OK sometimes in practice, but you can do it any > way you want. Well, client bootstrapping is typically performed in controlled environment so allowing initial trust for specific subnet is fine. > In short, this is not an easy issue, and the more "user-friendly" you > make it, the less secure it becomes, as usual. Cfengine chooses the > secure route. Regarding Cfengine security there is another point which is not yet clear for me (probably off-topic): cross-client access to configuration data. For example, let's say we have /etc/ssmtp/ssmtp.conf with unique clear-text password for each client machine and we want to manage it via policy server. If one of the clients gets compromised (its private key stolen), can attacker access other clients' ssmtp.conf files stored on the same Cfengine server (while public key isn't disabled of course)? What is recommended way to handle such situations without violating DRY principle (i.e. not having bunch of mostly identical ssmtp.conf files for each client and lots of access rules)? Thanks, Max _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
