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 <jce...@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 <redhatri...@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 <ma...@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: > >> > >> 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-le...@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 > > To unsubscribe send an email to > scap-security-guide-le...@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 > To unsubscribe send an email to > scap-security-guide-le...@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-le...@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
