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> 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:
>>
>> ...
>> _______________________________________________
>> 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.fedorahosted.org
>
> _______________________________________________
> 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.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-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.fedorahosted.org