Last year, we launched functionality for users to add policy for reporting data, compliance reports, promise types, and other code as modules. With CFEngine Build, users can manage and update their own policy, the default policy and any additional modules separately. This makes it very easy to utilize policy or other modules written by the CFEngine team, or other community members. In this post we will take a look at using some modules to improve the security of our infrastructure.
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.
Last year we had a look at managing local groups with the custom groups promise type. As you may or may not recall, we used JSON-strings to imitate CFEngine bodies. This was due to the fact that the promise module protocol did not support bodies at that time. Today, on the other hand, we’re happy to announce that as of CFEngine 3.20, this will no longer be the case. In this blog post we’ll introduce the long awaited feature; custom bodies.
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.
This is the final summary of our 2021 security hardening holiday calendar. We wanted to provide educational, useful, and actionable security advice, and we’re really pleased with the reception! Thank you for reading and following along.
Week 1-3 summary (1-21/25) We posted summaries for the 3 first weeks of the calendar:
Week 1 Week 2 Week 3 Enforce specific list of allowed sudoers (22/25) As discussed previously, the root user and sudo tool provide a lot of access to the system, both in terms of making changes, and reading sensitive data.
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.
This december, we are posting security advice and modules, every day until December 25th. Now, it’s December 21st, and we’ve gotten through most of the security hardening holiday calendar:
Week 1 & 2 summary (1-14/25) We posted summaries for the 2 first weeks of the calendar:
Week 1 Week 2 Disable prelinking (15/25) A technique called prelinking can be used to optimize programs, making them start up faster. As this feature will change the binary file, it interferes with security functionality such as checksumming and signatures.
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 /.
This december, we are posting security advice and modules, every day until December 25th. Now, it’s December 14th, and we’ve gotten to the fourteenth day of the security hardening holiday calendar:
Week 1 summary (1-7/25) If you didn’t see it yet, we posted a summary last week. Click here to read the security tips for day 1-7.
Non-root users with uid 0 (8/25) On most UNIX-like systems, there is a user called root, with an ID number 0 (uid).
Today, we are pleased to announce the release of CFEngine 3.19.0! In 2021, for this release, and the launch of CFEngine Build, our focus has been on collaboration. We want to deliver a lot of value to our users through modules, and enable you to share and cooperate on policy, promise types, compliance reports, etc. CFEngine 3.19 is not an LTS release, so the intention for us is to give you a chance to start testing and giving feedback on the new features we are developing, before they land in an LTS version next year.
