Hello,
I understand Gabe's point that containers are evolving and things which
we assumed in past may be changing. And I agree that we should react to
these changes to bring up-to-date experience for users.
As I understand it, changes which you are trying to revert in batch of
pull requests were done so that users performing container scans do not
get false positives e.g. Systemd services which are not running in
containers etc.
I agree that as these services start appearing in containers etc. we
should react. But I don't think that removing these limits is the right
solution. It can start generating false alarms and users will not
actually know what is happening, therefore they will not know how to
modify their configuration to make it compliant. They won't be happy.
Additionally, I think that creating multiple pull requests in this
fashion does not improve our workflow.
Your PRs touch many areas - some touch Systemd, some kernel modules etc.
I don't know this for sure but I think that reasoning why they received
the machine platform might not be the same for all of them. Some of them
might be easier to deal with than others. Can we distinguish these
categories and make them into some manageable chunks?
I think it is clear that we won't suddenly magically solve all Openscap
limitations which prevent some rules from being evaluated in containers.
But if we get some let's say prioritized list, we could consider it
while planing.
To put it short, let's make a plan how to gradually fix it instead of
suddenly breaking it all.
Best regards,
Vojta
Dne 28. 04. 20 v 18:57 Trevor Vaughan napsal(a):
I wrote a paper a while ago that may be of interest.
https://www.onyxpoint.com/blog/container-guidance-for-federal-information...
It's completely technology agnostic and has a focus on containers
instead of container ecosystems. As far as I know, the RH stack has
the ability to do everything contained within it and I *think* that
SCAP may be able to validate the majority of the items if implemented
in accordingly.
Overall, I think this is where OSCAL is going to come into play. We
need to be able to ship building blocks of compliance information
along to users that can be plugged together to present a full-scope
picture.
Trevor
On Tue, Apr 28, 2020 at 12:41 PM Gabe Alford <redhatrises(a)gmail.com
<mailto:redhatrises@gmail.com>> wrote:
Containers are changing from where we originally thought certain
practices were going to hold true. These ideas and practices no
longer hold true.
Kernel modules are going to start to be installed, delivered, and
configured through containers (delivered by Red Hat). SSH servers
are now running in containers (some delivered by Red Hat).
Systemd is running in containers (some also delivered by Red Hat).
Security and security content is not what someone thinks should or
shouldn't be in a container. It is about ensuring the container is
secured properly.
By not evaluating certain security rules, the container is
considered less compliant and more vulnerable especially with the
change in what is happening to containers.
Also, what OpenSCAP can and cannot do should never be the
determining factor in security content as many other security
vendors consume our content that don't have the same limitations
that OpenSCAP does.
The world has and is changing how it uses containers so that our
original assumptions are no longer valid. This (and the fact that
others consume our content) is why many PRs are reverting the
machine platform.
On Tue, Apr 28, 2020 at 10:16 AM Matej Tyc <matyc(a)redhat.com
<mailto:matyc@redhat.com>> wrote:
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+pla...
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.
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...