Prerequisite: Good knowledge of Docker, SELinux

1. Docker Security
Email : billal.ariif@gmail.com

2. Clair (Container Vulnerability Analysis
Service)
Clair is a container vulnerability analysis service. It provides a list of
vulnerabilities that threaten a container, and can notify users when
new vulnerabilities that affect existing containers become known.
Clair analyzes each container layer once, and does not execute the
container to perform its examination. The scanning engine extracts all
required data to detect known vulnerabilities, and caches layer data
for examination against vulnerabilities discovered in the future.

3. Analyze local images
This is a basic tool that allow
you to analyze your local Docker
images with Clair.
Images are made up of layers.
History of a image contain ID’s of

4. Image Layers Demo
We have locally available Ubuntu docker image
Now copy Image ID to check its History
Note that we have 4 layers

5. Run Ubuntu:14.04 image container to
introduce some new layers

6. Conti..
After installing nano we commit our container under new image name latest_ubuntu
Now again run Docker images to view ID of our new image 'latest_ubuntu'
And now lets compare history of both images, hopefully we will se extra layer in history of image
latest_ubuntu

7. Conti..

8. Conti..
Yes, here we go. Now we found another layer in the history of our new
container, due to installation of nano.

9. Clair Implementation
Pull Clair from git
# sudo docker pull quay.io/coreos/clair:latest
 Also download Clair config file from
https://github.com/coreos/clair/blob/master/config.example.yaml
And save in home directory with name config.yml in directory names config.
 Now run Clair container
# sudo docker run -p 6060:6060 -p 6061:6061 -v ~/config:ro quay.io/coreos/clair:latest --
config=/config/config.yaml

10. Analyze local Images implementation
 Now install Clair tool for Docker images Analysis (make sure you have installed GO before this)
# sudo go get -u github.com/coreos/clair/contrib/analyze-local-images
 Check for locally available images
# sudo docker images
 Copy targeted image ID
# sudo analyze-local-images <Docker Image ID>

11. Container Logs
Docker historically has handled logging is through the docker logs command - Docker captures
the STDOUT and STDERR of each container process, stores it on disk, and the user can query it
with docker logs <container>.

12. Docker Logs Demo
Host Machine Terminal:
Container Terminal:

13. Automating Docker Logging
But think about environment where hundreds of containers are running, cumbersome for
administrator to query and monitor each.
By automating the logs of all containers to a single place and then virtualization could make life
of administrator much easier.

14. The Approach
ElasticSearch to index the log data collected and make it more easily queryable
Logstash to act as a remote syslog to collect the logs from the containers
Logspout to actually send the container logs to Logstash
Kibana as a nice front end for interacting with the collected data
Cadvisor, a dashboard for monitoring container resource metrics, for kicks

15. sVirt
 sVirt is a technology included in Red Hat Enterprise Linux 6 that
integrates SELinux and virtualization. sVirt applies Mandatory Access
Control (MAC) to improve security when using virtual machines.
The default type we use for running Docker containers is
svirt_lxc_net_t. All container processes run with this type.
 All content within the container is labeled with the
svirt_sandbox_file_t type.
 svirt_lxc_net_t is allowed to manage any content labeled with
svirt_sandbox_file_t.

16. Conti..
 svirt_lxc_net_t is also able to read/execute most labels under /usr on the host.
 Processes running with the svirt_lxc_net_t are not allowed to open/write to
any other labels on the system. It is not allowed to read any default labels in /var,
/root, /home etc. Processes in the container are not isolated from each other or
the host OS.
To view policy of lxc_net run:
# cat /etc/selinux/targeted/contexts/lxc_contexts

17. Conti..
To view policy of lxc_net run:

18. Conti..
 The latest Daniel Walsh patch allow admins to setup the containers to run at a
specific level, which should satisfy the needs of MLS systems.
# sudo docker run -d --security-opt label:level:TopSecret --security-opt
label:type:docker_apache_t httpd
Here TopSecret is MLS label. MLS is defined next.

19. Multi-Level Security (MLS) and Multi-
Category Security (MCS).
MCS labeling from a user and system administrator standpoint is
straightforward. It consists of configuring a set of categories, which are simply
text labels, such as "Company_Confidential" or "Medical_Records", and then
assigning users to those categories.

20. Conti..
All this stuff is configured on Host, and results comes in form of audit logs in
/var/log/audit/audit.logs
Audit logs are difficult to understand by default.
We can assign specific logs identifiers to processes. Logs identifiers help in
searching right logs on right time

21. SeLinux Logs Demo
Lets add rule for Docker Daemon to log read write execute access with identifier 'dockerDaemon'
.
Now after restarting Docker service grep audit logs with our identifier.

22. References
https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-
host/7/container-security-guide/chapter-6-docker-selinux-security-policy
https://www.mankier.com/8/docker_selinux - this explains the entire Docker SELinux policy. It is
not in layman’s terms, but it is complete.
https://github.com/projectatomic/docker-selinux
http://crunchtools.com/securing-docker-svirt/
Daniel Walsh - https://opensource.com/business/14/7/docker-security-selinux
https://opensource.com/business/14/9/security-for-docker
https://opensource.com/business/15/3/docker-security-tuning