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-boun...@redhat.com
<open-scap-list-boun...@redhat.com> on behalf of
open-scap-list-requ...@redhat.com <open-scap-list-requ...@redhat.com>
*Sent:* Thursday, July 21, 2016 9:30 PM
*To:* open-scap-list@redhat.com
*Subject:* Open-scap-list Digest, Vol 88, Issue 11
Send Open-scap-list mailing list submissions to
open-scap-list@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-requ...@redhat.com
You can reach the person managing the list at
open-scap-list-ow...@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 <kpade...@redhat.com>
To: open-scap-list@redhat.com,
scap-security-gu...@lists.fedorahosted.org
Subject: [Open-scap] [xpost] BZ#1188570 Proposal for enhancement of
Docker SSG profile
Message-ID: <e711c0c5-8189-041c-7eec-0fc139221...@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 <jlies...@redhat.com>
To: Kaustubh Padegaonkar <kpade...@redhat.com>
Cc: SCAP Security Guide <scap-security-gu...@lists.fedorahosted.org>,
open-scap-list@redhat.com
Subject: Re: [Open-scap] [xpost] BZ#1188570 Proposal for enhancement
of Docker SSG profile
Message-ID:
<867690406.11254021.1469089915607.javamail.zim...@redhat.com>
Content-Type: text/plain; charset=utf-8
Hello Kaustubh,
thank you for the proposal.
----- Original Message -----
From: "Kaustubh Padegaonkar" <kpade...@redhat.com>
To: open-scap-list@redhat.com, scap-security-gu...@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-gu...@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-gu...@lists.fedorahosted.org
https://github.com/OpenSCAP/scap-security-guide/
------------------------------
_______________________________________________
Open-scap-list mailing list
Open-scap-list@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@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list
