

Linux Containers, Docker, and Security - sylvainkalache
http://www.slideshare.net/jpetazzo/linux-containers-lxc-docker-and-security

======
tptacek
Nothing here about crypto, and the risks of running crypto for two different
applications on the same kernel (and with the same CSPRNG state)
simultaneously.

<snark> But I'm sure if nobody's talking about it on Reddit, that must mean
it's not a big deal. </snark> ;)

~~~
zobzu
basically even if the container code was perfect (and its not) theres a bunch
of desgin issues security wise due to sharing the same kernel memory space.

kernel bugs affect all containers for example

~~~
adobriyan
> kernel bugs affect all containers for example

Fun fact: BSD jails have same (mis)design.

~~~
tptacek
It's weird to call it a "misdesign", since that attribute is fundamental to
the concept.

------
scarmig
I am terrified of containers. In 2012 I used lxc-destroy on a container, and
it managed to destroy my entire filesystem. It seems beyond belief to me that
something like that could happen, but it did.

Definitely unfair to bring it up at this point--it was a while back--but until
everyone universally says they're solid, I'm not touching them.

~~~
viraptor
Which filesystem? Host or container's? Either way, it's more likely that the
fs was already corrupted in that case - did you also stop using that
filesystem since then?

~~~
scarmig
Host's. Stopped using it once destroyed, just ended up re-installing Arch and
thanking the gods I had backups.

~~~
ithkuil
Wow. Any luck reproducing it?

EDIT: Anyway, it's probably an issue with the tooling around containers, not
the implementation of kernel containers itself (well, in theory it might have
been a bug in the kernel that corrupted the rootfs and you reported it here as
it has destroyed your host's system).

------
stefanha
The presentation makes a good point that containers aren't universally
"insecure".

For certain use cases they are absolutely fine because the trust boundary
between containers or the kernel isn't critical: * Deployment (immutable
servers) * Development environment (develop against same configuration as
production) * Test environment (try different distros)

But running multiple containers from untrusted parties on one host _is_ risky.
Let's face it, kernel exploits do come out periodically and when that happens,
container boundaries can be breached.

At the end of the day, security isn't absolute. You need to consider how
valuable your data is and make your own decision.

------
rwmj
It's worth noting that libvirt puts an (LXC) container around each regular KVM
virtual machine it runs, and will also secure it using SELinux (see: sVirt).

------
natejenkins
Can someone comment on the current state of Namespaces in Linux and how that
impacts LXC security? I found the following from 2012:
[http://lwn.net/Articles/528078/](http://lwn.net/Articles/528078/)

~~~
nopaste7
The slides are horrible outdated. Using Linux user namespaces you can have a
secure Linux container with a root within. And everyone who thinks that KVM is
totally secure need to go back to school.

~~~
natejenkins
any chance you have a good resource showing how to do this properly?

~~~
nopaste7
Yes, use libvirt-lxc and setup a uid-mapping.

------
Da_Blitz
This is pretty much spot on based on my experience writing containers
implementations. I have been putting together information documenting
containers and just added some notes about security earlier.

At the moment i am taking my notes on how to secure containers and attempting
to put them in a more digestible form unfortunately depending on what you are
trying to do with containers the security model and how you defend those
containers changes dramatically

if any one is interested in more info hit up
[http://doger.io](http://doger.io) and feel free to ask questions or request
specific information be posted

------
w0rm
Interesting to see this as just today I have decided to setup a new server
with LXC.

