A vulnerability was recently discovered in CFEngine Mission Portal and has now been fixed. Under certain circumstances, it was possible to inject JavaScript code into data presented in Mission Portal, that would be run in the user’s browser. This security issue was fixed in CFEngine 3.10.7, 3.12.3, and 3.15.0, and will be mitigated by upgrading your hub to one of these versions (or later). No other action is required than upgrading the Hub. This issue is present in CFEngine Enterprise 3.7 versions, 3.10.0 through 3.10.6, as well as 3.12.0, 3.12.1, and 3.12.2. All customers have been notified prior to this announcement and had time to address the issue. Any community users who use CFEngine Enterprise Free 25 should upgrade immediately. Open source versions of CFEngine (CFEngine Community) are not affected, as they do not include the Mission Portal Web UI. The security of the CFEngine product and our users is something we take very seriously, and we will continue to look for, fix and responsibly disclose serious weaknesses in our product(s). This issue has been registered as CVE-2019-19394 in the official public CVE registry. If you have any questions or concerns please contact CFEngine support if you have a support contract or email security@cfengine.com
About a year ago, I wrote a small python script to automate installing and bootstrapping CFEngine on virtual machines in AWS. It had some hard coded IP addresses that I needed to update when I spawned new hosts, but other than that, it worked well. During manual testing, it saved me a lot of time instead of having to do things manually. Deploying CFEngine normally consists of these steps:
Determine what CFEngine package to use. Download appropriate package if you haven’t already - curl. Copy the package to the host - scp. Log into the host - ssh. Install the package - rpm / dpkg. Bootstrap CFEngine - cf-agent -B. At a company hackathon I decided to make my script into something better, something that would be useful to my colleagues, and maybe even CFEngine users in general. Enter cf-remote.
cf-runagent is a component for triggering remote agent runs using the CFEngine network protocol. It does not allow for arbitrary commands to be executed, but rather asks the remote host to run the policy it already has. To trigger cf-runagent from other systems or web interfaces, you want to be able to run it as non-root.
Install and bootstrap I will use cf-remote to set up a demo hub running CFEngine Enterprise 3.12.1:
In some performance critical situations, it makes sense to limit management software to a single CPU (core). We can do this using systemd and cgroups. CFEngine already provides systemd units on relevant platforms, we just need to tweak them. I’m using CFEngine Enterprise 3.12 on CentOS 7, but the steps should be very similar on other platforms/versions. This post is based on an excellent article from Red Hat: https://access.redhat.com/solutions/1445073
Using ps to check what CPU core is utilized Listing all processes and their core We can use ps to check CPU core for desired processes:
