VMs, containers vs. bare-metal machines in SSG
by Martin Preisler
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.
--
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
6 years, 8 months
Importing to SecurityCenter
by Todd, Charles
Has anyone else zipped up one or more output files and gotten SecurityCenter ala ACAS to successfully scan with it?
I'm using the SSG in CentOS and openscap works great. SC recognizes the xccdf and rhel7 oval file zipped up as OVAL content. But I get errors about XML Schema validation when I actually scan. X-tool won't parse it either.
Thanks,
Charlie Todd
Ball Aerospace
This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.
7 years, 2 months
Re: Suggesting the addition of 'hidepid=2' to the /proc mount
by Paul Whitney
While I think this is a great feature to use, I would not make it mandatory. We have seen this feature impact functionality of certain applications when enabled.
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
Cell: 410.493.9448
Sent from my browser.
On Jan 19, 2017, at 11:19 AM, Trevor Vaughan <tvaughan(a)onyxpoint.com> wrote:
Hi All,
For some time now, I've been adding 'hidepid=2' to my systems to limit process list access to the users that own the processes themselves.
I would like to propose that this be added to the SSG since it provides a very straightforward mechanism for reducing system process enumeration by regular users and/or rogue daemons.
Thanks,
Trevor
--
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(a)lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org
7 years, 3 months
Suggesting the addition of 'hidepid=2' to the /proc mount
by Trevor Vaughan
Hi All,
For some time now, I've been adding 'hidepid=2' to my systems to limit
process list access to the users that own the processes themselves.
I would like to propose that this be added to the SSG since it provides a
very straightforward mechanism for reducing system process enumeration by
regular users and/or rogue daemons.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
7 years, 3 months
OpenSCAP 1.2.13
by Martin Preisler
Hello OpenSCAP users,
We are thrilled to announce the general availability of OpenSCAP 1.2.13.
This is the latest release from the maint-1.2 maintenance branch. API/ABI
are fully compatible with the 1.2.0 release. Users of 1.2.x releases are
recommended to update.
Changes:
- Maintenance
- we always build system_info OVAL probe, fixed configure output accordingly
- warn when the user requests to generate an ARF from XCCDF 1.1
- fixed a segfault when loading an OVAL file with invalid family attribute
- added --thin-results CLI override to oscap xccdf eval
- added --without-syschar CLI override to oscap xccdf eval
- fixed a segfault when freeing xccdf_policy of the default profile
- removed ARF schematron workaround when there are no applicable checks
- fixed verbose output in oscap xccdf generate fix
- do not filter fix by applicability when generating remediations from results
- fixed memory leaks, resource leaks and other minor issues
Download:
https://github.com/OpenSCAP/openscap/releases/download/1.2.13/openscap-1....
SHA512:
393b426f3278ab9438439df9a077b95b29bba66dfc2c799b7b40c2bf3980cf619aa1efc27225785ec780aa75926af6751b10fdb0b8d561c8056bf9a9a087792a
--
Martin Preisler
Identity Management and Platform Security | Red Hat, Inc.
7 years, 3 months
