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
findings not being detected properly.
by alsifius＠gmail.com
There are several items that are showing failures in spite of remediation. Where is the best place to search/file findings such as these. As an example, the scan fails even though the boot loader password is enabled and the root user is not listed.
Thank you.
-Al
7 years
troubleshooting with cmake
by Shawn Wells
still learning how to troubleshoot build processes with the new CMake
system (which I do love!).
Ran a build, got this:
> -- Scanning for dependencies of ubuntu1604 OVAL checks...
> -- Scanning for dependencies of wrlinux bash remediations...
> -- Scanning for dependencies of wrlinux ansible remediations...
> -- Scanning for dependencies of wrlinux puppet remediations...
> -- Scanning for dependencies of wrlinux anaconda remediations...
> -- Scanning for dependencies of wrlinux OVAL checks...
> -- Scanning for dependencies of webmin bash remediations...
> -- Scanning for dependencies of webmin ansible remediations...
> -- Scanning for dependencies of webmin puppet remediations...
> -- Scanning for dependencies of webmin anaconda remediations...
> -- Scanning for dependencies of webmin OVAL checks...
> -- Configuring incomplete, errors occurred!
> See also
> "/var/www/html/scap-security-guide/build/CMakeFiles/CMakeOutput.log".
The log doesn't tell me much:
> $ cat /var/www/html/scap-security-guide/build/CMakeFiles/CMakeOutput.log
> The system is: Linux - 3.10.0-514.6.1.el7.x86_64 - x86_64
Is there a verbose mode hiding somewhere?
7 years
xccdf_org.ssgproject URN
by Shawn Wells
We currently use "xccdf_org.ssgproject" -- should this be changed to
"xccdf_io.openscap" or "xccdf_org.open-scap"?
Has been bugging me for awhile.
For downstream, should we use xccdf_com.redhat?
7 years
Incorporating final DISA STIG / Release
by goobsoft＠gmail.com
DISA has released a STIG for RHEL 7. redhatrises updated an overlay to account for the final release from DISA of RHEL7 STIG. What additional work, if any, needs to be done to SSG in order for oscap to be able to scan relative to the final DISA STIG for RHEL 7?
When I clone the github repository, run cmake and examine build/ssg-rhel7-ds.xml, it shows xccdf_org.ssgproject.content_rule_encrypt_partitions select="true" for profile *STIG for Red Hat Enterprise Linux 7 Server Running GUI*. When I load up the final RHEL7 STIG, I can't find any vulnerability related to unencrypted partitions. Am I missing the vulnerability in the STIG, or is the SSG adding security checks to the profile?
Thanks,
Chad
7 years
RFC: chef.io Inspec
by nevion＠gmail.com
Hi folks,
I've watched the project for a couple of years now and done some work with it. I'm grateful many of you took the time to get SSG where it's at. Recently I came across chef.io's Inspec and I thought hey, this seems to solve alot of the engineering challenges the SSG project seems to have, especially with multi-distro support.
Github: https://github.com/chef/inspec
Product: https://www.chef.io/inspec/
Here are some of the benefits my eyes see:
* Content is centralized (less mutli-file editing for the same tests aka less XMHell :-)
* Content is encouraged to be less distribution specific but allowed to be as specific as it needs, and this is encouraged inside a module, meaning less versions are floating around in the codebase
* Declarative/Programmatic as opposed to Declaritive/document oriented - I'd say with the later case has led to somewhat awkward and hard write tests, in some cases
* Can test active configuration as well as configuration file state
* Looks significantly less verbose - as in saving 10x lines of sourcecode (not counting XML output) and developer productivity would be much higher
* and as a possible benefit, I wouldn't be surprised if tests ran much faster - though I have done no extensive tests to show this.
Most importantly I believe inspec could pave the way to all distros working off of a common and smaller codebase than the existing SSG implementation and be far less maintenance burden and as such I wanted to raise awareness and get a topic going on the ML.
Inspec doesn't seem compatible out right with openscap (or maybe it is - they have bidirectional oval/xccdf consumers/emitters), but it IS aiming to replace OVAL/XCCDF as something more sane and just plain old better for the tasks. They also have tools for running it without scap tools involved of course so it doesn't have to lean on openscap et al, but for some people being seperate from SCAP tools is going to be a con and not a pro.
7 years, 1 month
RFC: chef.io Inspec
by nevion＠gmail.com
Hi folks,
I've watched the project for a couple of years now and done some work with it. I'm grateful many of you took the time to get SSG where it's at. Recently I came across chef.io's Inspec and I thought hey, this seems to solve alot of the engineering challenges the SSG project seems to have, especially with multi-distro support.
Github: https://github.com/chef/inspec
Product: https://www.chef.io/inspec/
Here are some of the benefits my eyes see:
* Content is centralized (less mutli-file editing for the same tests aka less XMHell :-)
* Content is encouraged to be less distribution specific but allowed to be as specific as it needs, and this is encouraged inside a module, meaning less versions are floating around in the codebase
* Declarative/Programmatic as opposed to Declaritive/document oriented - I'd say with the later case has led to somewhat awkward and hard write tests, in some cases
* Can test active configuration as well as configuration file state
* Looks significantly less verbose - as in saving 10x lines of sourcecode (not counting XML output) and developer productivity would be much higher
* and as a possible benefit, I wouldn't be surprised if tests ran much faster - though I have done no extensive tests to show this.
Most importantly I believe inspec could pave the way to all distros working off of a common and smaller codebase than the existing SSG implementation and be far less maintenance burden and as such I wanted to raise awareness and get a topic going on the ML.
Inspec doesn't seem compatible out right with openscap (or maybe it is - they have bidirectional oval/xccdf consumers/emitters), but it IS aiming to replace OVAL/XCCDF as something more sane and just plain old better for the tasks. They also have tools for running it without scap tools involved of course so it doesn't have to lean on openscap et al, but for some people being seperate from SCAP tools is going to be a con and not a pro.
-Jason
7 years, 1 month
