Forum: CFEngine Help Subject: Re: Thoughts of encrypting the entire Cfengine workspace? Author: msvob...@linkedin.com Link to topic: https://cfengine.com/forum/read.php?3,25714,25753#msg-25753
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. Giving developers root access to development machines is a known evil. I would rather not give root access to people who aren't administrators, but in reality, this doesn't happen. Folks that run QA, performance environments, etc. want to be able to do basic administration to infrastructure they "own." Cfengine still runs on these machines, because ultimately, we still own them as well. Moving the policies off to a NFS server, or attempting to split the policies up isn't the right approach either. NFS is sketchy at best, unreliable at worse. cf-promises and cf-agent will downright hang itself if it attempts to access media on a NFS share that isn't responsive, causing cf-agent to pile up and a ton of cf-agents to linger in the process table. That just moves the unencrypted policies from local disk out to a NFS share, which is still readable and doesn't solve this problem. Check out cfsketch at 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. I haven't looked at cfsketch yet, but I have seen some of the discussion happening over on the design center. By splitting poilcies up to a per-host level, I just see the huge additional load in Cfengine administration. The power of using automation is that you write policies as generically as possible and bring your entire datacenter into convergance. If you split configuration up into small identicial chunks, administration overhead goes way up on where changes need to be made in policy files + complexity. I dont think this is the right approach.. 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... Ok, lets forget the shared key stored in cf-exced's anonymous memory segment for a bit... What if cf-agent pulled an encrypted bundle from cf-serverd, and then cf-serverd provided a one-time / one-use key to decrypt that bundle? That way, the decryption mechnasium doesn't live on the client. It lives on your master policy server. The hacker would have to break into the master policy server for the ability to decrypt the payload. This way, it doesn't matter what your client can do with root privledges on the client. He can't decrypt /var/cfengine without authentication to the master policy server. This breaks Cfengine's independance of firing off cf-agent execution without a network connection, but for the added value of security, I would personally enable it. The only other alternative here is to have the client destroy /var/cfengine/inputs, the policies, the configurations as the last policy it executed on every execution. Remove everything, and re-transfer the entire configuration payload on every execution. This is going to put a TON of work on cf-serverd, but, at least we wont have unencrypted configurations and policies residing on the filesystem. Thanks Mike _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
