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+platfo... 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.
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@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+platfo... 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:
- 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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
I wrote a paper a while ago that may be of interest.
https://www.onyxpoint.com/blog/container-guidance-for-federal-information-sy...
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@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@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+platfo... 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:
- 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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
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-sy...
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@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@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+platform%3Amachine 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@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org-- 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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
Hi,
I understand the changes in container practices. But I have some concerns.
For example, if we scan a container and evaluate the rule "service chronyd must be enabled" and the service isn't enabled in the container. The scanner will return the result "fail". Should we expect the user to review and waive the results that this particular container isn't supposed to run chronyd?
Then, there are also containerized services not managed by systemd, but defined as container's entrypoint in Dockerfiles.
Another example are the kernel options. Should the scanner somehow detect whether the container contains kernel modules and if not return "notapplicable"? Or should we leave this up to the user and waiving?
If we enable the rules, how to prevent false positives? Is the way to create tailored profiles for certain types of containers?
Regards
On Tue, Apr 28, 2020 at 6:42 PM Gabe Alford 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@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+platfo... 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:
Rules that are not applicable in containers, or rules that represent serious antipatterns (e.g. kernel-related rules, partition-related rules) Rules that can't be checked for in offline scans due to OVAL limitations (anything that requires the /proc filesystem) Rules that represent a likely antipattern (systemd in containers) 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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
The profile would need to be modified to only cover those items present in the container.
This matches the usual prose of "run only what you need". If the rules cannot be easily tailored to the environment that's a failure of the rules, not the environment.
Trevor
On Thu, Apr 30, 2020 at 6:10 AM Jan Cerny jcerny@redhat.com wrote:
Hi,
I understand the changes in container practices. But I have some concerns.
For example, if we scan a container and evaluate the rule "service chronyd must be enabled" and the service isn't enabled in the container. The scanner will return the result "fail". Should we expect the user to review and waive the results that this particular container isn't supposed to run chronyd?
Then, there are also containerized services not managed by systemd, but defined as container's entrypoint in Dockerfiles.
Another example are the kernel options. Should the scanner somehow detect whether the container contains kernel modules and if not return "notapplicable"? Or should we leave this up to the user and waiving?
If we enable the rules, how to prevent false positives? Is the way to create tailored profiles for certain types of containers?
Regards
On Tue, Apr 28, 2020 at 6:42 PM Gabe Alford 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@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+platfo...
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:
Rules that are not applicable in containers, or rules that represent
serious antipatterns (e.g. kernel-related rules, partition-related rules)
Rules that can't be checked for in offline scans due to OVAL
limitations (anything that requires the /proc filesystem)
Rules that represent a likely antipattern (systemd in containers) 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@lists.fedorahosted.org
To unsubscribe send an email to
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.fedor...
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to
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.fedor...
-- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
I second to Jan - what I have heard from both of you, Gabe and Trevor, is that we can expect legitimate use cases of containers with elevated privileges that would e.g. influence the kernel by directly setting modules, kernel parameters, time and so on.
From what I see, there is no automated way of how to tell whether a scanned container is meant to be privileged (ntp container will need privileges), or whether it is an omission or an attack attempt. Therefore, I don't see how removing this machine platform could be an improvement. I would expect specialized container profiles that Trevor has just mentioned to come first. Disable of the machine platform denomination makes a positive change only when those profiles are ready.
Matej
On 30. 04. 20 15:50, Trevor Vaughan wrote:
The profile would need to be modified to only cover those items present in the container.
This matches the usual prose of "run only what you need". If the rules cannot be easily tailored to the environment that's a failure of the rules, not the environment.
Trevor
On Thu, Apr 30, 2020 at 6:10 AM Jan Cerny <jcerny@redhat.com mailto:jcerny@redhat.com> wrote:
Hi, I understand the changes in container practices. But I have some concerns. For example, if we scan a container and evaluate the rule "service chronyd must be enabled" and the service isn't enabled in the container. The scanner will return the result "fail". Should we expect the user to review and waive the results that this particular container isn't supposed to run chronyd? Then, there are also containerized services not managed by systemd, but defined as container's entrypoint in Dockerfiles. Another example are the kernel options. Should the scanner somehow detect whether the container contains kernel modules and if not return "notapplicable"? Or should we leave this up to the user and waiving? If we enable the rules, how to prevent false positives? Is the way to create tailored profiles for certain types of containers? Regards On Tue, Apr 28, 2020 at 6:42 PM Gabe Alford <redhatrises@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@redhat.com <mailto:matyc@redhat.com>> wrote: >> >> ... >> _______________________________________________ >> scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> >> To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org -- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@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.fedorahosted.org-- 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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
On 4/30/20 12:05 PM, Matej Tyc wrote:
I second to Jan - what I have heard from both of you, Gabe and Trevor, is that we can expect legitimate use cases of containers with elevated privileges that would e.g. influence the kernel by directly setting modules, kernel parameters, time and so on.
From what I see, there is no automated way of how to tell whether a scanned container is meant to be privileged (ntp container will need privileges), or whether it is an omission or an attack attempt. Therefore, I don't see how removing this machine platform could be an improvement. I would expect specialized container profiles that Trevor has just mentioned to come first. Disable of the machine platform denomination makes a positive change only when those profiles are ready.
Fair enough. Is there interest to join the SCAP committees to create new probes that can handle these scenarios?
On 01. 05. 20 4:11, Shawn Wells wrote:
On 4/30/20 12:05 PM, Matej Tyc wrote:
I second to Jan - what I have heard from both of you, Gabe and Trevor, is that we can expect legitimate use cases of containers with elevated privileges that would e.g. influence the kernel by directly setting modules, kernel parameters, time and so on.
From what I see, there is no automated way of how to tell whether a scanned container is meant to be privileged (ntp container will need privileges), or whether it is an omission or an attack attempt. Therefore, I don't see how removing this machine platform could be an improvement. I would expect specialized container profiles that Trevor has just mentioned to come first. Disable of the machine platform denomination makes a positive change only when those profiles are ready.
Fair enough. Is there interest to join the SCAP committees to create new probes that can handle these scenarios?
Let's use the NTP example and let's do a thought experiment to see whether extending SCAP can help:
Consider a system that runs containers, and those containers are supposed not to be privileged except one, which is privileged, because of the NTP service it's supposed to run. You don't want two containers that are privileged and that run NTP, and let's say that in that particular case, you don't want a container that inserts kernel modules.
No machine can read the admin's mind, and it's the admin who knows that only container X is supposed to be privileged, and that only because of NTP, otherwise all remaining containers should run without any privileges.
On another system, admin may need two containers for kernel modules, but none for NTP, and so on.
Is there any other way how to satisfy everybody than to have a profile for unprivileged containers, and specialized profiles for privileged containers?
On 5/4/20 11:35 AM, Matej Tyc wrote:
On 01. 05. 20 4:11, Shawn Wells wrote:
On 4/30/20 12:05 PM, Matej Tyc wrote:
I second to Jan - what I have heard from both of you, Gabe and Trevor, is that we can expect legitimate use cases of containers with elevated privileges that would e.g. influence the kernel by directly setting modules, kernel parameters, time and so on.
From what I see, there is no automated way of how to tell whether a scanned container is meant to be privileged (ntp container will need privileges), or whether it is an omission or an attack attempt. Therefore, I don't see how removing this machine platform could be an improvement. I would expect specialized container profiles that Trevor has just mentioned to come first. Disable of the machine platform denomination makes a positive change only when those profiles are ready.
Fair enough. Is there interest to join the SCAP committees to create new probes that can handle these scenarios?
Let's use the NTP example and let's do a thought experiment to see whether extending SCAP can help:
Consider a system that runs containers, and those containers are supposed not to be privileged except one, which is privileged, because of the NTP service it's supposed to run. You don't want two containers that are privileged and that run NTP, and let's say that in that particular case, you don't want a container that inserts kernel modules.
No machine can read the admin's mind, and it's the admin who knows that only container X is supposed to be privileged, and that only because of NTP, otherwise all remaining containers should run without any privileges.
On another system, admin may need two containers for kernel modules, but none for NTP, and so on.
Is there any other way how to satisfy everybody than to have a profile for unprivileged containers, and specialized profiles for privileged containers?
Is that actually a use case people care about?
If NTP is installed, then make sure it's configured. Not sure thinking needs to go deeper than that.
Let the platform figure out who can run privileged containers. That's a problem of Pivotal/Docker/OpenShift etc. Not a problem of the SCAP content that makes sure the OS is configured.
If you're supplying a container, and it needs privileged access to function, then it should be able to bring everything that it needs along with it.
What's the point of 'bundled stuff' otherwise?
It's easy to punt to the OS/Admin but we're trying to make it easier for them instead of having them give up on the whole thing due to complexity.
On Mon, May 4, 2020 at 11:41 AM Shawn Wells shawn@redhat.com wrote:
On 5/4/20 11:35 AM, Matej Tyc wrote:
On 01. 05. 20 4:11, Shawn Wells wrote:
On 4/30/20 12:05 PM, Matej Tyc wrote:
I second to Jan - what I have heard from both of you, Gabe and Trevor, is that we can expect legitimate use cases of containers with elevated privileges that would e.g. influence the kernel by directly setting modules, kernel parameters, time and so on.
From what I see, there is no automated way of how to tell whether a scanned container is meant to be privileged (ntp container will need privileges), or whether it is an omission or an attack attempt. Therefore, I don't see how removing this machine platform could be an improvement. I would expect specialized container profiles that Trevor has just mentioned to come first. Disable of the machine platform denomination makes a positive change only when those profiles are ready.
Fair enough. Is there interest to join the SCAP committees to create new probes that can handle these scenarios?
Let's use the NTP example and let's do a thought experiment to see whether extending SCAP can help:
Consider a system that runs containers, and those containers are supposed not to be privileged except one, which is privileged, because of the NTP service it's supposed to run. You don't want two containers that are privileged and that run NTP, and let's say that in that particular case, you don't want a container that inserts kernel modules.
No machine can read the admin's mind, and it's the admin who knows that only container X is supposed to be privileged, and that only because of NTP, otherwise all remaining containers should run without any privileges.
On another system, admin may need two containers for kernel modules, but none for NTP, and so on.
Is there any other way how to satisfy everybody than to have a profile for unprivileged containers, and specialized profiles for privileged containers?
Is that actually a use case people care about?
If NTP is installed, then make sure it's configured. Not sure thinking needs to go deeper than that.
Let the platform figure out who can run privileged containers. That's a problem of Pivotal/Docker/OpenShift etc. Not a problem of the SCAP content that makes sure the OS is configured. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
On 5/4/20 12:51 PM, Trevor Vaughan wrote:
If you're supplying a container, and it needs privileged access to function, then it should be able to bring everything that it needs along with it.
What's the point of 'bundled stuff' otherwise?
It's easy to punt to the OS/Admin but we're trying to make it easier for them instead of having them give up on the whole thing due to complexity.
Believe we agree on the legitimacy of the challenge. Would contend conversation around privileged containers belongs to the container management platform.
eg in the OpenShift world the ability to run a privileged container is defined in a Security Context Constraint for the kubernetes pod. For the OpenShift SCAP content we would evaluate if "allowPrivilegedContainer" is true/false to organizational policy. Has nothing to do with configuration attestation of whatever is running /inside/ the container.
From a workflow perspective a compliance operator would scan the contents of the container image and the configuration of the pod. Behind the scenes this is likely two separate SCAP data streams but the user would only see one bundled scan.
Split streams makes sense.
* Inside the container (don't do bad things, pretty easy) * Outside the container (make sure it can't do bad things, harder because of immutability etc...)
On Mon, May 4, 2020 at 1:20 PM Shawn Wells shawn@redhat.com wrote:
On 5/4/20 12:51 PM, Trevor Vaughan wrote:
If you're supplying a container, and it needs privileged access to function, then it should be able to bring everything that it needs along with it.
What's the point of 'bundled stuff' otherwise?
It's easy to punt to the OS/Admin but we're trying to make it easier for them instead of having them give up on the whole thing due to complexity.
Believe we agree on the legitimacy of the challenge. Would contend conversation around privileged containers belongs to the container management platform.
eg in the OpenShift world the ability to run a privileged container is defined in a Security Context Constraint for the kubernetes pod. For the OpenShift SCAP content we would evaluate if "allowPrivilegedContainer" is true/false to organizational policy. Has nothing to do with configuration attestation of whatever is running /inside/ the container.
From a workflow perspective a compliance operator would scan the contents of the container image and the configuration of the pod. Behind the scenes this is likely two separate SCAP data streams but the user would only see one bundled scan. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
Le 04/05/2020 à 17:35, Matej Tyc a écrit :
Is there any other way how to satisfy everybody than to have a profile for unprivileged containers, and specialized profiles for privileged containers?
Hello everybody,
I find this discussion very intersting and I think because of the new raising ecosystem due to the massive use of containers, the way we are hardening system may be rethought (Or at least discussed)
Recently, I read that article https://lwn.net/Articles/796700/ quoting Stéphane Graber from Ubuntu/LXC project and I think he told something very very intersting :
"LXC and LXD are used to create "system containers", which run unmodified Linux distributions, not "application containers" like those created using Docker. The idea is that LXD users will use the same primitives as they would if they were running the distribution in a virtual machine (VM); that they are actually running them on a container is not meant to be visible to them."
After reading that, for me the first question to ask about hardening is not if the container is privileged or unprivileged but how it is built and how it is executed.
The article says (and I agree with it) that there are two categories of containers : - The application containers (Micro-service architecture) where the container is very minimalistic : Just the application,the dependencies, and nothing more (For example alpine based containers) - The system containers : If I sum up quickly, I would say it's a complete distribution with userland only (No kernel, no bootloader)
For me, if we must think about SCAP profiles for containers, it's easier with system containers because create such a profile could be "just" tailoring a current profile removing everything not applicable (I mean rules about kernel and bootloader). I would say it's a "userland SCAP profile".
For application containers, the approach is very diffent and with some of my colleagues we started to ask ourselves that question : Is it relevant to have an hardening profile on application containers which are very minimalistic ?
As I told before, a well built application container is very minimalistic with normaly only the application running. So generally, this is no authentication layer, no network configuration, no sysctl to configure (generally done at the host level). My point of view, is that when you try to reduce/tailor a SCAP profile for such a container, there is only very few rules to apply. Example: Why hardening a PAM stack which is never used or even not installed ?
Of course, it's just a first analysis with additional questions to answer : What about if you add privilege/unprivileged status and what about container who are between these two worlds ? (But for me the answer can be simple : The container is not well built).
So maybe a first approach would be to focus on these "system containers" and maybe try to define some guidelines for the "application containers" ?
My two cents !
Regards, Olivier Bonhomme
Hi Oliver,
Honestly, I'm 100% on board personally with the concept of 'system' and 'application' containers but industry is trying to pretend that system containers don't exist currently.
I think the new hotness (well, old if you ask Google) is VMs inside containers where we finally admit that Kubernetes is just a scheduler and nothing is new :-D.
Anyway, I don't really see this changing the problem space.
The main issue, in my opinion, is that we keep treating the operating system as a singular "thing" and it is simply not the case.
I think that the SCAP profiles should be bound to each individual application's configuration and they should all be layered using OSCAL. The recommended configurations would then float around with the application instead of a container, the OS, or anything else and inherit as necessary from the underlying operating system.
In a nutshell, this is the classic "system of systems" approach that we all decided was not worth the ROI some time around the birth of Agile. Frankly, I'm not sure if that was an incorrect assumption since we're generally about risk acceptance instead of a "perfect world".
So, if we (as an open source community) decide that things like SWID tags, SCAP, OVAL, and OSCAL are the way of the future then it needs to be moved into the community projects themselves. Otherwise, it's a nice niche area to build business models around that does, in my opinion, make a difference for those that choose to use it.
Trevor
On Mon, May 4, 2020 at 5:53 PM Olivier Bonhomme obonhomme@nerim.net wrote:
Le 04/05/2020 à 17:35, Matej Tyc a écrit :
Is there any other way how to satisfy everybody than to have a profile for unprivileged containers, and specialized profiles for privileged containers?
Hello everybody,
I find this discussion very intersting and I think because of the new raising ecosystem due to the massive use of containers, the way we are hardening system may be rethought (Or at least discussed)
Recently, I read that article https://lwn.net/Articles/796700/ quoting Stéphane Graber from Ubuntu/LXC project and I think he told something very very intersting :
"LXC and LXD are used to create "system containers", which run unmodified Linux distributions, not "application containers" like those created using Docker. The idea is that LXD users will use the same primitives as they would if they were running the distribution in a virtual machine (VM); that they are actually running them on a container is not meant to be visible to them."
After reading that, for me the first question to ask about hardening is not if the container is privileged or unprivileged but how it is built and how it is executed.
The article says (and I agree with it) that there are two categories of containers :
- The application containers (Micro-service architecture) where the
container is very minimalistic : Just the application,the dependencies, and nothing more (For example alpine based containers)
- The system containers : If I sum up quickly, I would say it's a
complete distribution with userland only (No kernel, no bootloader)
For me, if we must think about SCAP profiles for containers, it's easier with system containers because create such a profile could be "just" tailoring a current profile removing everything not applicable (I mean rules about kernel and bootloader). I would say it's a "userland SCAP profile".
For application containers, the approach is very diffent and with some of my colleagues we started to ask ourselves that question : Is it relevant to have an hardening profile on application containers which are very minimalistic ?
As I told before, a well built application container is very minimalistic with normaly only the application running. So generally, this is no authentication layer, no network configuration, no sysctl to configure (generally done at the host level). My point of view, is that when you try to reduce/tailor a SCAP profile for such a container, there is only very few rules to apply. Example: Why hardening a PAM stack which is never used or even not installed ?
Of course, it's just a first analysis with additional questions to answer : What about if you add privilege/unprivileged status and what about container who are between these two worlds ? (But for me the answer can be simple : The container is not well built).
So maybe a first approach would be to focus on these "system containers" and maybe try to define some guidelines for the "application containers" ?
My two cents !
Regards, Olivier Bonhomme
-- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Jan Cerny -
Matej Tyc -
Olivier Bonhomme -
Shawn Wells -
Trevor Vaughan -
Vojtech Polasek