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. We’ll have a look at it from both the policy writers- and the promise module developers point of view.
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. That’s what this post is about, using cfbs with your traditionally manged policy set. Note: This post assumes that you already have cfbs installed and understand the basics of how it works. Check out our previous blog posts if you want to review how to get started with cfbs.
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:
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. Agencies have until 5pm EST on December 23rd, 2021 to comply with the requirements of the directive.
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. For these reasons it is generally a good idea to disable prelinking, unless you really need it.
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 /. When run as root a vulnerable version of sudo will display an error sudoedit: /: not a regular file.
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.
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.
This year we decided to provide security focused modules and content for the holiday season. These are parts of the security configuration we implement on our own infrastructure, based on OpenSCAP and other sources. By putting these into easy to use modules and writing about it, we hope to give our community of users something valuable: Educational and easy to understand security tips, along with configuration which can quickly be automated across your entire infrastructure, using CFEngine. Today, at the seventh day of the calendar, we will share a summary of the first week.
Join us as we embark on an adventure to create and publish a new CFEngine Build module.
Nick (Doer of Things) demonstrates he knows the proper offerings the gods require by writing and publishing a new CFEngine Build Module from scratch, live, with no safety net!
Video The video recording is available on YouTube:
At the end of every webinar, we stop the recording for a nice and relaxed, off-the-record chat with attendees. Join the next webinar to not miss this discussion.
