On 19/01/17 18:40, Watson Yuuma Sato wrote:
On 20/10/16 20:30, Martin Preisler wrote:
> We have had increasing requests to scan containers and VM storage images
> for compliance. In those use-cases a lot of our rules don't make sense.
> For example separate partition for /tmp isn't really applicable to
> containers.
>
> I thought about how we can deal with this in SSG. We have several
> options:
>
> 1) Separate benchmark and datastreams for containers and VM storage
> images:
> ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml
>
> 2) Separate profile for containers and VM storage images:
> pci-dss and pci-dss-container
>
> 3) Use applicability and CPE platforms to distinguish between what is
> being
> scanned. That allows us to use the same pci-dss profile for
> bare-metal, VM,
> VM storage image and container image.
>
> Right now I am leaning towards 3) because it "unlocks" the feature
> transparently to our users. There is nothing extra they have to study to
> start scanning containers. The downside is that we will have to add
> "fake"
> CPE IDs for platforms like "vm-storage" and "container". Rules
that
> apply
> to everything will have no <platform> element in them. Rules that apply
> to just containers will have something like:
>
> <platform idref="cpe:/a:*:container-image"/>
>
> or
>
> <platform idref="cpe:/a:*:vm-storage"/>
>
> Official NIST CPE ID dictionary has these related CPE IDs
> cpe:/a:redhat:docker:1.5.0-27
> cpe:/a:linuxcontainers:lxc:0.5.0
> cpe:/a:redhat:libvirt:1.2.7
>
> Not sure we want to go with any of those though. I would like to keep it
> container and VM tech agnostic.
>
> Before I start hacking this I would like to hear your thoughts.
>
Hi folks,
Following idea 3, here is a WIP PR to tackle this matter.
https://github.com/OpenSCAP/scap-security-guide/pull/1645 The PR is in a state good
for review.
Changes are not intended to be extensive and complete, the aim is to get
the ball
rolling and check whether we are in the same page regarding how to mark
the rules.
Thank you.
Please, share your concerns...
--
Watson Sato
Security Technologies | Red Hat, Inc
--
Watson Sato
Security Technologies | Red Hat, Inc