Rules for a subsystem should only apply if the subsystem to which they
apply actually exist on the system.
1) The *Docker* methodology for containers would have us not use SSH in
containers, but the LXC/LXD methodology (the OG of containers) would.
2) There is no reason that you need to have SSH on a bare metal machine if
it is set up properly and there is an out of band methodology for accessing
the system in an emergency (the same goes for containers really)
Presently, the system is upside down. We're looking at the OS as a single
entity when, in reality, it is a collection of subsystems that work
independently, or in concert, to create a whole.
If the SSG were decomposed into sections that applied to each individual
subsystem, then only those parts that required application could be applied
appropriately across any set of given processes. This would fit both the
Docker and traditional-style systems equally.
On Tue, Aug 15, 2017 at 6:19 AM, Watson Yuuma Sato <wsato(a)redhat.com> wrote:
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
>> I thought about how we can deal with this in SSG. We have several
>> 1) Separate benchmark and datastreams for containers and VM storage
>> 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
>> scanned. That allows us to use the same pci-dss profile for bare-metal,
>> 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
>> 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"/>
>> <platform idref="cpe:/a:*:vm-storage"/>
>> Official NIST CPE ID dictionary has these related CPE IDs
>> 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.
> Please, share your concerns...
> Hello again,
Following idea 3, most of obvious (e.g. partition, grub, kernel) rules got
marked as machine using CPE "cpe:/a:machine".
Now there are some Rules witch are harder to decide whether they make
sense or not for containers.
Take for example, Rules related to sshd.
Technically, ssh can run fine in a container, but it is not recommended,
there are other ways to access a running container.
An exception to running ssh in, is that this container's purpose is to be
an ssh server.
If mark these as machine only they will never apply to containers and we
will need new Rules to evaluate ssh inside containers.
If they are left as is, they will continue to be evaluated for containers,
installing ssh, increasing attack surface and possibly causing false
We would like SSG to have sane defaults for these Rules, but still allow
for tailoring for exception scenarios.
I started a
prototype for Idea 1, to have separate datastreams for containers. But that
showed to not be a good idea.
So I changed it to idea 2, with separate Profiles for containers. Main
idea is to generate these Profiles automatically from existing Profiles and
use information already present in Rules to filter out the ones not
recommended for containers.
Also, there is new idea of adding "container-base" Profile with basic
configuration for containers, I see it like a "standard" Profile for
So, container Profiles would have Rules which are not recommended for
containers dropped, and inherit Rules from "container-base".
Looking forward for your thoughts.
Security Technologies | Red Hat, Inc
scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
To unsubscribe send an email to scap-security-guide-leave@list
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --