Presentation for openSUSE Asia Summit 2015. Here I explained what kind of security risk Docker is having, and how can we reduce the risk by using AppArmor.

1. AppArmor UseCases with Docker system
Kazuki Omo( 面 和毅 ): ka-omo@sios.com
SIOS Technology, Inc.

2. 2
Who am I ?
- Security Researcher/Engineer (15 years)
- SELinux/MAC Evangelist (10 years)
- SIEM Engineer (3 years)
- Linux Engineer (15 years)

3. Security Risks of Docker Applications

4. 4
What is Docker ? (you know...)
Docker is
- for separate each App UserSpace (container).
- cgroups/namespaces for containers.
- for App/Userspace Portability
→ Not for Creating Secure environment!!

5. 5
Security Risks of Docker Applications
- Which UID is running your docker container?
- root can bypass access control (Discretionary Access Control)
- What will happen if App has vulnerability?
- What will happen if the OS/kernel has vulnerability?
- Can you trust Docker-Hub image?
Not only desk theory...

6. 6
Security Risks of Docker Applications
- Do you really think “Container” is safety sandbox?
ex. VENOM(VM) +Local root Exploit
CVE-2014-6408, CVE-2014-6409
We have to Protect Docker process !!

7. What is AppArmor

8. 8
What is AppArmor
Do you know AppArmor?
- Provide “Mandatory Access Control( 制 控制强 访问 )”
- Restrict root(UID=0) permission.
- Process under AppArmor is in separate domain.
- Same as SELinux, but not so complicated. :-p
AppArmordomain
domain
inherit

9. 9
What is AppArmor
/var/www/html
httpd
When you use Apparmor,
- easy to control permission even if “UID=0”.
docker_httpd
/etc/shadow

10. 10
What is AppArmor
/var/www/html /etc/shadow
httpd
When you use Apparmor,
- easy to control permission even if “UID=0”.
docker_httpd
Tiny shell

11. Docker /AppArmor Usecase

12. 12
Docker Security Option
Option: --security-opt
- After Docker 1.3
- Attach to Container;
- SELinux Label
- AppArmor Domain
We can use AppArmor Access Control!!

13. 13
Docker with AppArmor
Sample:)
docker –security-opt=apparmor:docker_httpd_web1 XXXX
/etc/apparmor.d/local/docker_httpd_web1
#include <tunables/global>
profile docker_httpd_web1
flags=(attach_disconnected,mediate_deleted,complain) {
#include <abstractions/base>
deny @{PROC}/sys/fs/** wklx,
}

14. 14
Docker with AppArmor
docker_httpd_web1 (enforce) 5352 root /usr/bin/python /usr/bin/supervisord
docker_httpd_web1 (enforce) 5396 root /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) 5397 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) 5398 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5389 root /usr/bin/python /usr/bin/supervisord
docker_httpd_web2 (enforce) 5402 root /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5403 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5404 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
ps axZ

15. 15
Docker with AppArmor
/var/www/html /etc/shadow
httpd
- Each container(web1/web2) separated with AppArmor domain.
- If web2 cracked with zero-day, web1 and others are safe. :-)
docker_httpd_web1
/var/www/html
httpd(?)
docker_httpd_web2

16. 16
Docker with AppArmor UseCase.
Many Single-App-Containers on 1 host.
Web
Python
DB
Web1
Web2
Web3
DB
Each container has own AppArmor Domain.
Web Domain
Python Domain
DB Domain
Web1 Domain
Web2 Domain
Web3 Domain
DB Domain

17. 17
Docker with AppArmor UseCase.
Multi-App-Containers on 1 host.
Web Python DB
Web Python DB
Container_1 Domain
Inside container , same AppArmor Domain
→ Not good idea from security point of view.
Container_2 Domain

18. 18
AppArmor Domain Transition
Domain can transit to another Domain in Profile rule.
#include <tunables/global>
profile docker_test_parent flags=(…..)
{
#include <abstractions/base>
/usr/sbin/httpd-prefork px -> docker_httpd_web1,
deny @{PROC}/mem rwklx,,
docker_test_parent_web1
docker_httpd_web1
Docker parent
docker_test_parent_web1 docker_httpd_web1

19. 19
AppArmor Domain Transition
docker_test_parent_web1 (enforce) root 2545 /usr/bin/python
/usr/bin/supervisord
docker_httpd_web1 (enforce) root 2566 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) wwwrun 2583 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) wwwrun 2584 /usr/sbin/httpd-prefork -D
FOREGROUND
---------------------------------------------------------------------------------------------------------------
docker_test_parent_web2 (enforce) root 2581 /usr/bin/python
/usr/bin/supervisord
docker_httpd_web2 (enforce) root 2593 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) wwwrun 2594 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) wwwrun 2595 /usr/sbin/httpd-prefork -D
FOREGROUND
ps axZ

20. 20
Docker with AppArmor UseCase
(with Domain transition)
Multi-App-Containers on 1 host.
Web
Python
DB
Container 1 DomainWeb_Con1
Py_Con1
DB_Con1
Web
Python
DB
Web_Con2
Py_Con2
DB_Con2
More Safe :)
Container 2 Domain

21. Conclusion

22. 22
Conclusion
- Docker will be more secure by
using “--security-opts”.
- Multi-Apps container by Docker
will be secured by using AppArmor.
:-)

23. 23
Any Questinos?

24. 24
Thank You!!!
謝謝！！

25. AppArmor UseCases with Docker system
Kazuki Omo( 面 和毅 ): ka-omo@sios.com
SIOS Technology, Inc.
Hello Everyone
Thanks for attending this session.
In this session, I'll discuss the
Docker's security issues, and how
we can control the issues with
AppAromor.

26. 2
Who am I ?
- Security Researcher/Engineer (15 years)
- SELinux/MAC Evangelist (10 years)
- SIEM Engineer (3 years)
- Linux Engineer (15 years)
Here is my background for security and OSS
area.
I spent almost 15 years for Security
Researching and Business.
Also I have experience to inplement those kind
of Security Product to customer(Big customer
to small).
And I was working as SELinux(you know)
Evangelist 4 years.

27. Security Risks of Docker Applications
At first. I wish to discuss how the
docker's security Risk.

28. 4
What is Docker ? (you know...)
Docker is
- for separate each App UserSpace (container).
- cgroups/namespaces for containers.
- for App/Userspace Portability
→ Not for Creating Secure environment!!
So, I guess almost everyone in here have
experience to use Docker with your
Linux+Application.
The Docker's concept is making container by
using cgroups/namespaces/capabilities with
current Linux system. Sometime we imagine
it's concept is similar as chroot, but Docker is
more flexible system. Then current IT
engineer, admin or dev or vendor are
interested to use Docker with their system.
But we should imagine that the Docker's
concept is “making container for running
several Apps on same OS/system”, and the
concept is not coming from “How to create
secure container.”

29. 5
Security Risks of Docker Applications
- Which UID is running your docker container?
- root can bypass access control (Discretionary Access Control)
- What will happen if App has vulnerability?
- What will happen if the OS/kernel has vulnerability?
- Can you trust Docker-Hub image?
Not only desk theory...
So, these are famous questions when we are
discussing about Docker's security scheme
issue.
Docker's problem is
1. not using it's own UID, and docker process
are running by “root”.
So if docker is having any critical issue, we
might have issue to get root priviledge by
cracker.
2. And root can do anything, then the cracker
can do anything on your OS.
So now we have to think about “how can we
protect docker process by cracker”.

30. 6
Security Risks of Docker Applications
- Do you really think “Container” is safety sandbox?
ex. VENOM(VM) +Local root Exploit
CVE-2014-6408, CVE-2014-6409
We have to Protect Docker process !!
So, these are famous questions when we are
discussing about Docker's security scheme
issue.
Docker's problem is
1. not using it's own UID, and docker process
are running by “root”.
So if docker is having any critical issue, we
might have issue to get root priviledge by
cracker.
2. And root can do anything, then the cracker
can do anything on your OS.
So now we have to think about “how can we
protect docker process by cracker”.

31. What is AppArmor
OK, in next step, I wish to talk a
little bit about AppArmor.

32. 8
What is AppArmor
Do you know AppArmor?
- Provide “Mandatory Access Control( 制 控制强 访问 )”
- Restrict root(UID=0) permission.
- Process under AppArmor is in separate domain.
- Same as SELinux, but not so complicated. :-p
AppArmordomain
domain
inherit
So, in here, how many people know about
AppArmor?
Have you experience to use AppArmor on your
system?
Thanks. Here I described what is AppArmor.
The AppArmor is providing Mandatory Access
Control to your Linux. Usually, root can
escape OS Access Control, DAC. But in MAC,
even if root can not escape Access Control,
and control by MAC ACL.
This MAC can reduce the root/privileged ID's
risk in the process.
Most famous MAC system is SELinux, but it's a
little bit messy to use in Actual system.
AppArmor is more easy to understand, and

33. 9
What is AppArmor
/var/www/html
httpd
When you use Apparmor,
- easy to control permission even if “UID=0”.
docker_httpd
/etc/shadow
So here is a graphical example how the
AppArmor working.
Each process under AppArmor control has
domain, called profile. In this example, gray
one “docker_httpd” is profile.
Each profile, we have to describe which
file/dir/object the process can
open/write/read, etc…
And default permission is “deny”.
So If the httpd process with docker is linked
with “docker_httpd” profile and the profile is
saying it can open/read “/var/www/html”, it
only can open/read “var/www/html” and
can't do anything to other un-listed file, such
as /etc/shadow or something.
Then we can use this AppArmor MAC for

34. 10
What is AppArmor
/var/www/html /etc/shadow
httpd
When you use Apparmor,
- easy to control permission even if “UID=0”.
docker_httpd
Tiny shell
So here is a graphical example how the
AppArmor working.
Each process under AppArmor control has
domain, called profile. In this example, gray
one “docker_httpd” is profile.
Each profile, we have to describe which
file/dir/object the process can
open/write/read, etc…
And default permission is “deny”.
So If the httpd process with docker is linked
with “docker_httpd” profile and the profile is
saying it can open/read “/var/www/html”, it
only can open/read “var/www/html” and
can't do anything to other un-listed file, such
as /etc/shadow or something.
Then we can use this AppArmor MAC for

35. Docker /AppArmor Usecase
OK, here I'll describe how Docker
is working with AppArmor MAC
scheme.

36. 12
Docker Security Option
Option: --security-opt
- After Docker 1.3
- Attach to Container;
- SELinux Label
- AppArmor Domain
We can use AppArmor Access Control!!
After Docker 1.3, docker program is having
security option, such as “--security-opt”.
With this option, we can use SELinux Label or
AppArmor Profile with container which is
provided by Docker.
Then we can use AppArmor Access Control.

37. 13
Docker with AppArmor
Sample:)
docker –security-opt=apparmor:docker_httpd_web1 XXXX
/etc/apparmor.d/local/docker_httpd_web1
#include <tunables/global>
profile docker_httpd_web1
flags=(attach_disconnected,mediate_deleted,complain) {
#include <abstractions/base>
deny @{PROC}/sys/fs/** wklx,
}
Here is just sample. Docker is created for
providing httpd web server.
When we wish to run docker+Apache, we will
run “docker run XXX –security-
opt=apparmor:[Profile Name]”, then the
httpd and other process under the docker will
run with [Profile Name] profile.

38. 14
Docker with AppArmor
docker_httpd_web1 (enforce) 5352 root /usr/bin/python /usr/bin/supervisord
docker_httpd_web1 (enforce) 5396 root /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) 5397 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) 5398 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5389 root /usr/bin/python /usr/bin/supervisord
docker_httpd_web2 (enforce) 5402 root /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5403 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) 5404 wwwrun /usr/sbin/httpd-prefork -D
FOREGROUND
ps axZ
So, this is process list.
You can see web1 container related process,
such as supervisord and httpd, are running
with docker_httpd_web1.
Also web2 container related process, such as
supervisord and httpd, are running with
docker_httpd_web2.
In this case, what will happen? See next slide.

39. 15
Docker with AppArmor
/var/www/html /etc/shadow
httpd
- Each container(web1/web2) separated with AppArmor domain.
- If web2 cracked with zero-day, web1 and others are safe. :-)
docker_httpd_web1
/var/www/html
httpd(?)
docker_httpd_web2
So, web1's httpd are running under
docker_httpd_web1. Web2's httpd are also
under docker_httpd_web2. If httpd has zero-
day issue and malicious user or cracker
attack web2's apache and get root access,
The malicious user or cracker only can get
“docker_httpd_web2” profile.
Then, cracker can only do anything with
their /var/www/html, but can't do anything to
other profile container, such as
docker_httpd_web1, or un-listed /etc/shadow
etc.
Then we can localize the damage to only web2
container.

40. 16
Docker with AppArmor UseCase.
Many Single-App-Containers on 1 host.
Web
Python
DB
Web1
Web2
Web3
DB
Each container has own AppArmor Domain.
Web Domain
Python Domain
DB Domain
Web1 Domain
Web2 Domain
Web3 Domain
DB Domain
In this senario, we ca run several Web server
on 1 host. Each container has it's own
AppArmor profile, then the damage will be
localized even if we have Zero-day attack.

41. 17
Docker with AppArmor UseCase.
Multi-App-Containers on 1 host.
Web Python DB
Web Python DB
Container_1 Domain
Inside container , same AppArmor Domain
→ Not good idea from security point of view.
Container_2 Domain
But now, let's consider about Multi-App
container.
For example, the container is running MySQL,
HTTPD, and Python.
Every process in the container are having
same AppArmor Profile.
In this case, we can localize the risk in each
container, but if httpd have problem, MySQL
in same container will have security risk.
From security point of view, this is not good
idea.

42. 18
AppArmor Domain Transition
Domain can transit to another Domain in Profile rule.
#include <tunables/global>
profile docker_test_parent flags=(…..)
{
#include <abstractions/base>
/usr/sbin/httpd-prefork px -> docker_httpd_web1,
deny @{PROC}/mem rwklx,,
docker_test_parent_web1
docker_httpd_web1
Docker parent
docker_test_parent_web1 docker_httpd_web1
For resolving this issue, we can use Profile
transition. It is AppArmor feature, and it's
more like process/child process concept.
Parent process is using a profile, and there is a
description how the profile will transition to
other in “the” profile, child process will have
new profile.
In this example, parent process,
docker/supervisord will have
docker_test_parent_web1 profile, httpd which
is child of the supervisord will have
“docker_httpd_web1”, different profile.
If we will use this profile tranisiton, we can
separate each process's profile in same
container.

43. 19
AppArmor Domain Transition
docker_test_parent_web1 (enforce) root 2545 /usr/bin/python
/usr/bin/supervisord
docker_httpd_web1 (enforce) root 2566 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) wwwrun 2583 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web1 (enforce) wwwrun 2584 /usr/sbin/httpd-prefork -D
FOREGROUND
---------------------------------------------------------------------------------------------------------------
docker_test_parent_web2 (enforce) root 2581 /usr/bin/python
/usr/bin/supervisord
docker_httpd_web2 (enforce) root 2593 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) wwwrun 2594 /usr/sbin/httpd-prefork -D
FOREGROUND
docker_httpd_web2 (enforce) wwwrun 2595 /usr/sbin/httpd-prefork -D
FOREGROUND
ps axZ
So, In this is process list, we can see
supervisord for web1 is running with
“docker_test_parent_web1” profile, and httpd
for web1 is running with docker_httpd_web1.
Here is only supervisord and httpd, but we will
be able to create other profile for each apps
in the container if we have. Such as mysqld,
python, and so on.

44. 20
Docker with AppArmor UseCase
(with Domain transition)
Multi-App-Containers on 1 host.
Web
Python
DB
Container 1 DomainWeb_Con1
Py_Con1
DB_Con1
Web
Python
DB
Web_Con2
Py_Con2
DB_Con2
More Safe :)
Container 2 Domain
So, if we will use Docker + AppArmor with
profile transition, we can localize the risk in
1. each container
2. each apps in the container.
This will be more safe system, then I wish to
recommend this.

45. Conclusion
Concolusion.

46. 22
Conclusion
- Docker will be more secure by
using “--security-opts”.
- Multi-Apps container by Docker
will be secured by using AppArmor.
:-)
So, now we know Docker security risk, but we
can control the risk by using AppArmor.
For using AppArmor with Docker, we can use
“--security-opts” option.
And using AppArmor, and profile transition, we
can create more secured system with Docker
+ Multi container.

47. 23
Any Questinos?

48. 24
Thank You!!!
謝謝！！