-
Notifications
You must be signed in to change notification settings - Fork 681
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ocp4: Remove fapolicyd checks from RHCOS moderate profile #5351
Conversation
This package is not applicable to RHCOS and will not be included. So Lets remove it.
/ok-to-test |
/woof |
1 similar comment
/woof |
In response to this:
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. |
/test all |
2 similar comments
/test all |
/test all |
/lgtm |
/assign @jhrozek |
@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. In response to this:
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. |
/retest |
/test all |
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 |
Can one of the admins verify this patch? |
@JAORMX understand their hesitation. A read-only
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. |
I really appreciate the work everyone in the security field is doing - we live in a world of constant threats.
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.
At some point soon we will likely implement reliable extensions. So that will make it ergonomic for people who want it to install |
fapolicyd should already handle that.
fs-verity is complimentary with fapolicyd and not a replacement. Container handling is on the roadmap already for fapolicyd.
|
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:
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.
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. |
@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. |
I see it as an optional extension: coreos/fedora-coreos-tracker#401
https://github.com/openshift/os/blob/master/FAQ.md#q-what-is-coreos
"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. |
This package is not applicable to RHCOS and will not be included. So
Lets remove it.