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
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
https://github.com/OpenSCAP/scap-security-guide/
