Forum: CFEngine Help Subject: Re: Thoughts of encrypting the entire Cfengine workspace? Author: sauer Link to topic: https://cfengine.com/forum/read.php?3,25714,25792#msg-25792
Encryption just slows things down, and if you have a policy which prevents non-root users from accessing the policy at the filesystem level (ie, setting permissions correctly), you've already got the same level of protection. As has been mentioned before - if the root account on a machine is compromised, you're done. Period. using some encryption which can automatically be decrypted is an excercise in futility. Saying "well, most users can't see memory" is questionable at best - someone who has root access should be assumed to know how to manipulate the system. If they don't, well, your root access policies are done wrong. Making it more inconvenient has a high cost in the common case, and only gains a very incremental level of protection. How about I, as an attacker, replace the system library that reads from a file with one which copies any read data to my file, and then passes the data through to the real library / program? One "LD_LIBRARY_PATH=/home/attacker cf-ag ent" later, and all that encryption work is lost. Or how about I just use strace. Or whatever; there's a million and one ways to read a local file which can be locally decrypted without human intervention - if someone controls the computer, they can make the computer do anything the computer can do. Does that need repeated? :) If the computer can decrypt something all by itself, than someone with full control over the computer can do the exact same thing. The only way you truly protect information is to only put information on the system which that system and all root users on that system are authorized to access. In my architecture, I have a directory which contains one file per hostname. Those files are managed in subversion, and all are created by an "svn copy" from a template directory. I can make local changes per-host (making sure that they're made in a way that doesn't break a future svn merge), and any global changes to the perhost files get made in the template and svn merge'd to all the per-host configs. The individual hosts have a promise which gets the file named perhost/$(sys.uqname) from the master. For more "groups of hosts" things, I have another directory like "applications" which has application-specific config files. The classes which define per-group config files are defined in promises.cf, and then if the class matches, that .cf file is added to a "get_extra_files" array. The array's contents are get_indecies'd into an slist which is used for the common control include directive, the bundlesequence (each file starts with a bundle named the same as the file), and the update bundle - which pulls any relevant files down to an applications/ directory under inputs. The one part of this puzzle which CFEngine doesn't do well for me is restricting access to the restricted configs. If I was only managing a few hosts, I could define individual access rules in the server control body. But I haven't been able to figure out how to grant access based on a variable representing the connecting server name. I'd like to do a rule restricting access like "perhost/$(sys.remotehostname)". But the best I have found is to define an slist of all known hosts and create a rule based on "$(allhostlist)" - which requires me to define a massive slist consisting of literally thousands of hosts which is updated potentially hundreds of times daily. The server doesn't like having that many rules and I don't like maintaining that, so I've left that part out - meaning I'm still vulnerable to someone gaining root access and writing a policy to download the configs for other servers or non-local applications. Probably the "more manageable" solution is to buy the commercial version and use remote scalars instead of passing out a bunch of files, but there's still the access control problem; this just reduces the number of files I'd have to manage. :) There's also the related problem of managing all of those per-host files across several CFEngine masters, as CFEngine (3.2.x and earlier, anyway)doesn't seem to handle copying really large directories (like 180K entries currently) in sync as efficiently as something like rsync or svn update. But that can easily be handled by not using CFEngine's file transfer mechanism to keep the masterfiles in sync. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
