[Open-scap] BZ#1188570 Proposal for enhancement of Docker SSG profile
Kaustubh Padegaonkar
kpadegao at redhat.com
Fri Jul 22 09:21:28 UTC 2016
Hello Pravin,
Thank you for the suggestions.
> On Friday 22 July 2016 03:50 AM, Pravin Goyal wrote:
> Hi All,
>
> Not sure, if you are aware of CIS Docker Security Benchmark. This is one
> of its kinds and contains comprehensive checks for Docker platform
> covering images, runtime, host and everything else.
Yes, I am aware of the CIS benchmark. Some of the items in the proposal,
viz. #2, #5 are included from the benchmark.
>
> https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf
> It is regularly updated and currently Docker 1.12 benchmark development
> is in progress.
Thank you for the information, I was unaware of recent developments.
>
> For doing container runtime checks and image level checks, we would
> require to add a new probe to OVAL schema and then implement it in
> OpenSCAP. However, host level checks could be done currently.
That's right. I was thinking of something on similar lines. I am not
sure whether we are/should be targetting host level checks.
Also, as Jan mentioned in another email, the tool cannot invoke other
binaries (such as docker info subcommand) so we need to look at
alternate methods on achieving that.
>
> Thanks and regards,
> Pravin Goyal
> CIS Docker 1.11.0 Benchmark - benchmarks.cisecurity.org
> <https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf>
> benchmarks.cisecurity.org
> 6 | P a g e Overview This document is intended for system and
> application administrators, security specialists, auditors, help desk,
> and platform deployment personnel ...
>
>
>
>
> ------------------------------------------------------------------------
> *From:* open-scap-list-bounces at redhat.com
> <open-scap-list-bounces at redhat.com> on behalf of
> open-scap-list-request at redhat.com <open-scap-list-request at redhat.com>
> *Sent:* Thursday, July 21, 2016 9:30 PM
> *To:* open-scap-list at redhat.com
> *Subject:* Open-scap-list Digest, Vol 88, Issue 11
>
> Send Open-scap-list mailing list submissions to
> open-scap-list at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/open-scap-list
> or, via email, send a message with subject or body 'help' to
> open-scap-list-request at redhat.com
>
> You can reach the person managing the list at
> open-scap-list-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Open-scap-list digest..."
>
>
> Today's Topics:
>
> 1. [xpost] BZ#1188570 Proposal for enhancement of Docker SSG
> profile (Kaustubh Padegaonkar)
> 2. Re: [xpost] BZ#1188570 Proposal for enhancement of Docker SSG
> profile (Jan Lieskovsky)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Jul 2016 13:25:23 +0530
> From: Kaustubh Padegaonkar <kpadegao at redhat.com>
> To: open-scap-list at redhat.com,
> scap-security-guide at lists.fedorahosted.org
> Subject: [Open-scap] [xpost] BZ#1188570 Proposal for enhancement of
> Docker SSG profile
> Message-ID: <e711c0c5-8189-041c-7eec-0fc1392217a1 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Jul 2016 04:31:55 -0400 (EDT)
> From: Jan Lieskovsky <jlieskov at redhat.com>
> To: Kaustubh Padegaonkar <kpadegao at redhat.com>
> Cc: SCAP Security Guide <scap-security-guide at lists.fedorahosted.org>,
> open-scap-list at redhat.com
> Subject: Re: [Open-scap] [xpost] BZ#1188570 Proposal for enhancement
> of Docker SSG profile
> Message-ID:
> <867690406.11254021.1469089915607.JavaMail.zimbra at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
>
> Hello Kaustubh,
>
> thank you for the proposal.
>
> ----- Original Message -----
>> From: "Kaustubh Padegaonkar" <kpadegao at redhat.com>
>> To: open-scap-list at redhat.com, scap-security-guide at 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:
>>
>>
>> 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.
>
> 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 [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.
>
>>
>>
>> 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
> means).
>
>>
>>
>> 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.
>
> 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.
>
>>
>>
>> 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 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.
>
>>
>>
>> 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.
>
> 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-libcontainer/
>> [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 at lists.fedorahosted.org
>> https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorahosted.org
>> https://github.com/OpenSCAP/scap-security-guide/
>>
>
>
>
> ------------------------------
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
>
> End of Open-scap-list Digest, Vol 88, Issue 11
> **********************************************
>
>
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
>
--
Kaustubh Padegaonkar,
Software Engineer, Red Hat
irc: thetuxracer
More information about the Open-scap-list
mailing list