[Open-scap] [xpost] BZ#1188570 Proposal for enhancement of Docker SSG profile

[Kaustubh Padegaonkar]

Hello members,

With regards to BZ#1188570 [0], 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 [1]. 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.


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 [2]. 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 
userland packages.


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


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 
registry.access.redhat.com 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 [3]. 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 
their liking.


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.


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.

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.



[Hyperlinks]
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1188570
[1]: https://docs.docker.com/engine/userguide/storagedriver/selectadriver/
[2]: 
https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
[3]: https://registry.access.redhat.com/v1/repositories/library/rhel7/tags

Best Regards,

-- 
kdp
irc: thetuxracer