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... [3]: https://registry.access.redhat.com/v1/repositories/library/rhel7/tags
Best Regards,
Hello Kaustubh,
thank you for the proposal.
----- Original Message -----
From: "Kaustubh Padegaonkar" kpadegao@redhat.com To: open-scap-list@redhat.com, scap-security-guide@lists.fedorahosted.org Sent: Thursday, July 21, 2016 9:55:23 AM Subject: [xpost] BZ#1188570 Proposal for enhancement of Docker SSG profile
Hello members,
With regards to BZ#1188570 [0], I, would like to propose inclusion of below checks into the docker SSG profile:
- 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.
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.
- 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.
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 via OVAL.
- 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 means).
- 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.
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 investigation.
- 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 Security: https://fedorapeople.org/~dwalsh/Presentations/ContainerSecurity/#/
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.
- 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.
Right.
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.
[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... [3]: https://registry.access.redhat.com/v1/repositories/library/rhel7/tags
Best Regards,
Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- kdp irc: thetuxracer -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Kaustubh Padegaonkar