thank you for the proposal.
----- Original Message -----
From: "Kaustubh Padegaonkar" <kpadegao(a)redhat.com>
To: open-scap-list(a)redhat.com, scap-security-guide(a)lists.fedorahosted.org
Sent: Thursday, July 21, 2016 9:55:23 AM
Subject: [xpost] BZ#1188570 Proposal for enhancement of Docker SSG profile
With regards to BZ#1188570 , I, would like to propose inclusion of
below checks into the docker SSG profile:
1. Checking if docker-storage-setup is completed or configured:
- For using docker in production, the device mapper storage driver, with
loopback devices is discouraged . There are various ways of
configuring the devicemapper storage driver, and suggested ones are
aufs, direct-lvm. Choosing the right storage driver and backing
filesystem is crucial to stability and performance.
Makes sense to me.
From the very brief look the storage driver information
used by docker daemon can be queried using 'docker info' command.
Unfortunately in OVAL it's not possible to call external executables
to query system information, so we will need to find a different way
how to get the information about storage driver used by docker
(the directive doesn't seem to be configured in docker.conf too).
Just thinking out how this could be implemented.
2. Ensuring that the LXC execution driver isn't used:
- LXC as an execution driver has legacy support at best, and should not
be used . libcontainer is the default docker execution driver. All
kernel interactions and manipulation of namespaces and control groups
are easily achieved from libcontainer without having to rely on other
Makes sense to me. Again, 'Execution Driver' information can be queried
via 'docker info'. But we would need to find out a way how to check this
3. A container should be created with a non-root user
- Newer docker versions come with user namespaces enabled. This largely
allows security by way of containment of users and groups so that
processes running root in a container are not root on the host system.
However, docker versions older than 1.9 do not utilize user namespaces
and hence any process started as root inside the container can exploit
loopholes within the system and lead to privilege escalation or even
denial of services. Even better is to create a non-root user solely for
the purpose of running the container
Definitely makes sense. This should be possible to verify immediately
(read like it should be possible to write corresponding OVAL using existing
4. A container should be built from a trusted source
- Docker images should be built from trusted and official docker or
docker partner repositories. Examples would be
or registries marked official on docker.io.
To accomplish this, the image's hash can be inspected. For Red Hat, base
images, SHA is hosted at . I do not know of APIs to check SHAs of
official images hosted on hub.docker.com
, this is something that I would
like to hear alternate approaches, should the members find this point to
ACK. We would need to identify the keys for official Docker Hub repo. Also
we might need to add OVAL test for Docker image hashes. Needs further
5. Check for disabled kernel capabilities
- The report should mention the capabilities that the container runs
with and without. This will help user to gain an understanding of the
various capabilities that a container can run with and makes user aware
of the necessities of each. By running the container with only the bare
minimum capabilities, the attack surface is reduced to quite an extent.
ACK. Definitely makes sense. Besides of the capabilities check I would recommend
to add checks for features depicted in Dan's presentations focused on Container
To mention some example, e.g. rule / requirement
"Run your services as non Root whenever possible"
makes sense to me as possible candidate too (and there are more of them, see the slides).
For the implementation details - not sure how oscap will query the capabilities the
container has been started with (maybe they are in the metadata, maybe we would need
to implement custom queries). => subject of further investigation yet.
6. A container should not have ssh package installed
- Running ssh inside the container necessitates the installation of
openssh server/client and adds to complexity of security management
because its difficult to audit and keep track of ssh keys. It also
becomes difficult to consume security updates to the openssh packages
caused by CVE/RHSA. Docker provides an inbuilt way to obtain shell
access to a container which should be used rather than an ssh package.
Definitely makes sense. The practice to launch sshd just to obtain remote
access to the container is discouraged on multiple places (can provide the
links if necessary). So agree this requirement is useful IMHO.
These suggestions are by no means comprehensive; I wish to merely use
these as a starting point to create more exhaustive tests in the profile
itself. Dan Walsh's container security guide is a good start.
Please feel free to critique or provide suggestions.
As mentioned in the private email. I have created new SSG "Docker SSG profile"
label. Once other people react on the proposal and there's consensus
on the list of new rules / requirements to be implemented, could you file
new SSG tickets and couple them with that label?
This could allow us to split the effort into smaller chunks, focus on
specific rules, and determine what will need to be implemented yet (both
in OVAL standard on one hand, but also in the oscap scanner on the other
hand) the implementation of these to be feasible.
Thank you && Regards, Jan
Jan iankko Lieskovsky / Red Hat Security Technologies Team
> irc: thetuxracer
> SCAP Security Guide mailing list