scap-security-guide May 2020

scap-security-guide@lists.fedorahosted.org

5 participants
3 discussions

ComplianceAsCode Content 0.1.50
by Vojtech Polasek 15 May '20

15 May '20

Hello all, ComplianceAsCode/Content 0.1.50 has been released. Among the highlights of this release are: - Add initial macOS content - Feature suse 15 For full release notes, please have a look at: - https://github.com/ComplianceAsCode/content/releases/tag/v0.1.50 Zip archive with pre-built content: https://github.com/ComplianceAsCode/content/releases/download/v0.1.50/scap-… Zip archive with pre-built content using only OVAL-5.10: https://github.com/ComplianceAsCode/content/releases/download/v0.1.50/scap-… Thank you to everyone who contributed! Happy hardening! VojtÄch PolĂĄĹĄek

1 0

Stabilization of v0.1.50
by Vojtech Polasek 11 May '20

11 May '20

Hello all, *Release of Content version 0.1.50 is scheduled for May 15th*, so I've created a stabilization branch for it. Now is a good time to hunt for bugs and propose fixes for them. Starting today, merged Pull Requests should be assigned to milestone v0.1.51. As the branch has been created on Wednesday May 6, I also moved closed pull requests created after this date to 0.1.51 milestone. Bug fixes should be proposed to master and labeled "bugfix", they will be cherry-picked to the stabilization branch. Please note that we plan to release version 0.1.51 earlier than usual. The release is planed on June 19th 2020 with stabilization starting on June 5th. Best regards, Vojta

1 0

The Machine Platform Great Controversy
by Matej Tyc 05 May '20

05 May '20

Hello everybody, there are now numerous PRs upstream now that disable the machine platform designation of certain rules - see https://github.com/ComplianceAsCode/content/pulls?q=is%3Apr+is%3Aopen+platf… Historically, this project uses one profile that is intended to scan both running systems and container images. Obviously, scanning of lifeless filesystems (a.k.a offline scanning) is limited, and the machine platform has been used to control rule applicability to such environments (i.e. environments other than running bare-metal systems or VMs). This way is cheap, a bit dirty, and the following categories of rules ended up being machine-only: 1. Rules that are not applicable in containers, or rules that represent serious antipatterns (e.g. kernel-related rules, partition-related rules) 2. Rules that can't be checked for in offline scans due to OVAL limitations (anything that requires the /proc filesystem) 3. Rules that represent a likely antipattern (systemd in containers) 4. Rules that OpenSCAP can't properly offline-scan. It is quite clear that in case No. 4, removal of the machine platform is the right thing to do, although it is likely to cause problems elsewhere. However, it is at best questionable in case 3. For example, there is a way to determine whether we are scanning a filesystem of a systemd-powered container, and execute the check accordingly, but until all the bits are in place, removing the platform from the rule will make the situation worse for the majority of use cases. Therefore, I suggest that we reach a consensus about what to do with those PRs, as they are making the list of open PRs difficult to navigate in. My proposal is to close all PRs that touch rules falling into categories 1-3, as those PRs don't make the situation any better.

7 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide May 2020