ocp4: Remove fapolicyd checks from RHCOS moderate profile

[JAORMX]

This package is not applicable to RHCOS and will not be included. So
Lets remove it.

[JAORMX]

/ok-to-test

[petr-muller]

/woof

[petr-muller]

/woof

[openshift-ci-robot]

@petr-muller:

In response to this:

/woof

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[petr-muller]

/test all

[JAORMX]

/test all

[petr-muller]

/test all

[isimluk]

[mrogers950]

/lgtm

[JAORMX]

/assign @jhrozek

[openshift-ci-robot]

@JAORMX: GitHub didn't allow me to assign the following users: jhrozek.

Note that only ComplianceAsCode members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @jhrozek

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[JAORMX]

/retest

[JAORMX]

/test all

[redhatrises]

I am going to kindly nack this change. This is a requirement for RHCOS to meet both moderate and high. Contrary to belief, this is more than just about rpms, it is about binaries that can be installed on coreos with tools like wget and curl. In addition, the team is looking at container handling to meet this requirement.

[JAORMX]

I am going to kindly nack this change. This is a requirement for RHCOS to meet both moderate and high. Contrary to belief, this is more than just about rpms, it is about binaries that can be installed on coreos with tools like wget and curl. In addition, the team is looking at container handling to meet this requirement.

The RHCOS team have been quite adamant in not including this package. On the other hand, the executable files from /usr are already in a read-only partition, wouldn't this indirectly address the issue? it's non-trivial to get non-approved executable binaries in RHCOS due to this fact.

[openscap-ci]

Can one of the admins verify this patch?

[redhatrises]

I am going to kindly nack this change. This is a requirement for RHCOS to meet both moderate and high. Contrary to belief, this is more than just about rpms, it is about binaries that can be installed on coreos with tools like wget and curl. In addition, the team is looking at container handling to meet this requirement.

The RHCOS team have been quite adamant in not including this package. On the other hand, the executable files from /usr are already in a read-only partition, wouldn't this indirectly address the issue? it's non-trivial to get non-approved executable binaries in RHCOS due to this fact.

@JAORMX understand their hesitation. A read-only usr partition doesn't meet the requirements for moderate and high or NIST's guidance for software blacklisting/whitelisting for more than a couple of reasons. So have a few questions:

• How is RHCOS going to prevent the execution of the binaries based off of an approved (RHT default) or customer defined whitelist?
• How is RHCOS going to eliminate days of work validating binary hashes during forensic investigations?
• How is RHCOS going to prevent malicious or untrusted software from running?
• How is RHCOS going to help to prevent data exfiltration?
• How is RHCOS going to prevent abuses by having bash/awk installed?
• How is RHCOS going to prevent installation and execution of software in rw (non-/usr) areas?
• How is RHCOS going to prevent some malware abuse cases as fapolicyd is a malware prevention tool?
• fapolicyd could have prevented not only Dirty Cow but the recent BPF exploit. How is RHCOS going to do this?
• How will we describe to customers that the Common Criteria certified component that performs whitelisting is present in RHEL, but not CoreOS? Aren't they supposed to be the same?

The team working on fapolicyd is also tasked with investigating tackling containers, flatpacks, etc.

Also starting this calendar year, many of our Government customers are now required to go through a cybersecurity maturity certification which requires them to meet a refined list of moderate controls (NIST 800-171) with no exceptions (i.e. no POAM).

fapolicyd meets all of the above and more and ensures a really awesome security story when added to RHCOS.

[cgwalters]

How is RHCOS going to prevent malicious or untrusted software from running?

I really appreciate the work everyone in the security field is doing - we live in a world of constant threats.

and ensures a really awesome security story when added to RHCOS.

That said...my feelings on fapolicyd are quite similar to that on the AIDE approach.

Among the enormous, yawning gaps in fapolicyd are...well, containers. Kind of important for OpenShift. Another is systemd unit files which are also arbitrary code.

Again my preferred architecture is to start with complete code signing/integrity for the OS (up to and including the root filesystem via fs-verity), then also create a design to extend that to the privileged containers that run as part of OpenShift. Simultaneously, we need to come up with a model that allows customers to sign privileged changes (custom MachineConfigs, systemd units in /etc) with their own key and enroll that key in the chain. That model should extend to signing privileged daemonsets and the like.

How will we describe to customers that the Common Criteria certified component that performs whitelisting is present in RHEL, but not CoreOS? Aren't they supposed to be the same?

At some point soon we will likely implement reliable extensions. So that will make it ergonomic for people who want it to install fapolicyd. But, that doesn't solve the issues above.

[redhatrises]

How is RHCOS going to prevent malicious or untrusted software from running?

I really appreciate the work everyone in the security field is doing - we live in a world of constant threats.

and ensures a really awesome security story when added to RHCOS.

That said...my feelings on fapolicyd are quite similar to that on the AIDE approach.

Among the enormous, yawning gaps in fapolicyd are...well, containers. Kind of important for OpenShift. Another is systemd unit files which are also arbitrary code.

Again my preferred architecture is to start with complete code signing/integrity for the OS (up to and including the root filesystem via fs-verity), then also create a design to extend that to the privileged containers that run as part of OpenShift. Simultaneously, we need to come up with a model that allows customers to sign privileged changes (custom MachineConfigs, systemd units in /etc) with their own key and enroll that key in the chain. That model should extend to signing privileged daemonsets and the like.

How will we describe to customers that the Common Criteria certified component that performs whitelisting is present in RHEL, but not CoreOS? Aren't they supposed to be the same?

At some point soon we will likely implement reliable extensions. So that will make it ergonomic for people who want it to install fapolicyd. But, that doesn't solve the issues above.

How is RHCOS going to prevent malicious or untrusted software from running?

I really appreciate the work everyone in the security field is doing - we live in a world of constant threats.

and ensures a really awesome security story when added to RHCOS.

That said...my feelings on fapolicyd are quite similar to that on the AIDE approach.

Among the enormous, yawning gaps in fapolicyd are...well, containers. Kind of important for OpenShift. Another is systemd unit files which are also arbitrary code.

fapolicyd should already handle that.

Again my preferred architecture is to start with complete code signing/integrity for the OS (up to and including the root filesystem via fs-verity), then also create a design to extend that to the privileged containers that run as part of OpenShift. Simultaneously, we need to come up with a model that allows customers to sign privileged changes (custom MachineConfigs, systemd units in /etc) with their own key and enroll that key in the chain. That model should extend to signing privileged daemonsets and the like.

fs-verity is complimentary with fapolicyd and not a replacement. Container handling is on the roadmap already for fapolicyd.

How will we describe to customers that the Common Criteria certified component that performs whitelisting is present in RHEL, but not CoreOS? Aren't they supposed to be the same?

At some point soon we will likely implement reliable extensions. So that will make it ergonomic for people who want it to install fapolicyd. But, that doesn't solve the issues above.

[mrguitar]

Gabe, I'm glad to hear this is on the roadmap. What details can you share about the timeline and policies for OpenShift? Also, please let us know who you're working with in OpenShift so we can help coordinate the right time to included it and get feedback from QE. I'm sure you can appreciate that we're not going to include RPMs in RHEL CoreOS that don't work with OpenShift.

Also, this question also didn't sit well:

How will we describe to customers that the Common Criteria certified component that performs whitelisting is present in RHEL, but not CoreOS?

We should start by being honest about the technology's capabilities regarding containers, and not oversell the certification as OpenShift releases move too quickly for the CC process.

Aren't they supposed to be the same?

RHEL CoreOS is an appliance, built from RHEL RPMs, delivered as part of OpenShift. Red Hat Enterprise Linux is a general purpose operating system that is incredibly versatile and can fit a vast array of use cases. The rpms we include are "the same" because they're from RHEL, but as we've discussed in the past, we intentionally do not include all of RHEL's packages in RHEL CoreOS.

[shawndwells]

@JAORMX @redhatrises @mrguitar I am going to merge this patch. At the end of the day, CoreOS does not ship fapolicyd right now, and as a result, it will be impossible for CoreOS systems to satisfy this control.

The long-term conversation of how to include fapolicyd into CoreOS is extremely important. Lack of fapolicyd demonstrates to customers that CoreOS is not "just RHEL" or "just a EULA difference".... but an entirely different operating system with a different package composition. The weaker security capabilities should give customers pause about using CoreOS -- especially since it is missing fundamental subsystems that were part of the RHEL Common Criteria.

But ComplianceAsCode isn't the place to debate product RFEs. It's a place to create config baselines that attest product settings in effect now.

[cgwalters]

The long-term conversation of how to include fapolicyd into CoreOS is extremely important.

I see it as an optional extension: coreos/fedora-coreos-tracker#401

Lack of fapolicyd demonstrates to customers that CoreOS is not "just RHEL"

https://github.com/openshift/os/blob/master/FAQ.md#q-what-is-coreos

The weaker security capabilities should give customers pause about using CoreOS -- especially since it is missing fundamental subsystems that were part of the RHEL Common Criteria.

"Weaker security capabilities" is a pretty strong phrase, and not one I'd agree with.

Anyways per above I think the extension mechanism will help us bridge the gap and for those customers that want to turn it on, can - but enabling it by default is a much more debatable thing, much like usbguard. But these can be separate conversations.