What’s autorun? Autorun is a feature of the Masterfiles Policy Framework (MPF)1 that simplifies the process of adding and executing new policy. We have talked about Modular policies with autorun and the Augments before. This time, we dig into autorun a bit deeper to explore some of its current features and look at how to implement your own as we did during The Agent is In, Episode 15 - Extending Autorun
A recent change in the Masterfiles Policy Framework (MPF) is renaming bundle agent main to bundle agent mpf_main. This change is intended to make it easier to run individual parts of your policy leveraging the library main bundle functionality (bundle agent __main__). Library main bundles were first introduced in CFEngine 3.12.0. The functionality allows for the definition of bundle agent __main__. When this bundle definition is present in the policy entry (the first policy file that CFEngine reads) the bundle is understood to be used as the default bundlesequence.
rxdirs has provided a convenient default when setting permissions recursively. When enabled (the default prior to version 3.20.0) a promise to grant read access on a directory is extended to also include execution since quite commonly if you want to read a directory you also want to be able to list the files in the directory. However, the convenience comes with the cost of complicating security reviews since the state requested on the surface is more strict than what is actually granted.
The CFEngine engineering team has recently discovered two security issues in the CFEngine Enterprise product, specifically in the hub package: CVE-2021-44215 - PostgreSQL log file world readable. CVE-2021-44216 - Apache and Mission Portal Application log files world readable. CVE-2021-44215 is a regression affecting currently supported versions 3.18.0 and 3.15.4 as well as some unsupported versions. CVE-2021-44216 affects all supported versions prior to 3.18.1 and 3.15.5 as well as some unsupported versions.
I re-stumbled across this mailing list post from Bryan Burke about some policy framework upgrade issues where he also asked about hooking in and customizing the update policy. I thought this sounded like a good opportunity for an example using a cfbs module. So, let’s take a look at making a cfbs module for a custom update policy. As mentioned in the thread there are just a couple of things you need to do in order to hook in and customize the behavior of the update policy.
With the recent release of build.cfengine.com and cfbs I have been thinking about the process of converting a traditionally manged policy set. I consider a traditionally manged policy set one where you have a repo with the root of masterfiles being the root of the repository, or even having no repository at all and managing masterfiles by editing directly in the distribution point (e.g. /var/cfengine/masterfiles). Before jumping in with both feet and converting to a cfbs managed policy set you might want a hybrid situation where you can leverage some of the benefits of cfbs but without making drastic changes to the way policy is currently managed.
The internet has been ablaze since the announcement of Log4Shell, the nickname for CVE-2021-44228, an arbitrary remote code execution vulnerability in the Java logging utility Log4j. So far two additional vulnerabilities (CVE 2021-45046, CVE-2021-45105) have been identified. If you are interested in how the vulnerability works, this graphic from SecurityZines explains it well: The code has been vulnerable since 2013 and millions of hosts and services are affected. The US Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive on December 17th, 2021 ordering all civilian federal agencies to take a series of measures to identify, patch, or mitigate vulnerable systems.
In January of 2021 Qualys security researchers discovered a heap overflow vulnerability in sudo, an extremely common tool installed in most Unix and Linux operating systems. Sudo allows users to execute programs with the privileges of another user but the vulnerability allows any unprivileged user to gain root on a vulnerable host. This specific vulnerability was nicknamed “Baron Samedit”. The Buffer overflow in command line escaping blog post on sudo.ws notes that the vulnerability can be tested by executing sudoedit -s /.
With the release of build.cfengine.com, I have been working to migrate some of our own security related policy into modules of their own. CFEngine Build and the cfbs tooling allows us to organize policy into modules, which are easy to update independently and share with other users. Let’s take the scenic route and look at what life is like with cfbs. One of our security policies requires that the password hashing algorithm in /etc/login.
When working with CFEngine, it’s common to hear advice about separating data from policy. Separating data from policy allows for separation of concerns, delegation of responsibilities and integration with other tooling. Each organization is different, and a strategy that works well in one environment may not work as well in a similar environment of another organization, so CFEngine looks to provide various generic ways to leverage external data. For example, Augments (def.
Sign up for CFEngine Enterprise and connect up to 25 hosts for free. No credit card required. Get started in minutes.
Try enterprise for free
