21–30 of 60 posts
It's perfectly possible to fire up a regular docker container inside KVM or whatever. With constant container security issues, why isn't this the norm?
This may be an unpopular opinion, but containers and Docker specifically shouldn't be used to isolate systems for security. It should be used to ease deployment.
Containers' raison d'être is to provide isolation. Just like chroot, they are used for security. If the security mechanism fails, it's good to have defense-in-depth, as usual. From reading the article it appears the issue is in Docker, not the container mechanism offered by the kernel upon which Docker builds.
I do agree that a it's important to have defence in depth
Earlier quoted context omitted.
Does your recommendation still stand when Docker used in conjunction with SELinux (and SELinux categories for tennancy isolation)?
That seems like lazy contrarianism. If you put docker inside a VM, and your hypervisor is running in a zone, and you have different zones based on ”role”. Then of course you get the benefits of the zone and the hypervisor. The parent said “docker solves deployment, not isolation”- if you get your isolation another way then there’s no issue with using docker.
Run well written software. As a user. In a cgroup. With SELinux. On a VM. On Different Tin. With a security monitoring. Patch.
Why don't people run containers in VM's? I don't get it, the only real selling point I can come up with for kernel level isolation is ability to over provision ram. And you shouldn't do that on a server anyways. It's perfectly possible to fire up a regular docker container inside KVM or whatever. With constant container security issues, why isn't this the norm?
https://clearlinux.org/news-blogs/intel-clear-containers-now... https://katacontainers.io/
Earlier quoted context omitted.
Containers' raison d'être is to provide isolation. Just like chroot, they are used for security. If the security mechanism fails, it's good to have defense-in-depth, as usual. From reading the article it appears the issue is in Docker, not the container mechanism offered by the kernel upon which Docker builds.
Isolation doesn't mean secure. Some containerisation solutions are designed to provide a security mechanism. Other containerisation solutions, such as Docker, are designed as a development and/or orchestration tool. I do agree that a it's important to have defence in depth
Well, thousands of companies, such as ISPs offering VPS are using containers for exactly that reason. Containers use cgroups under the hood, a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. As long as there aren't any bugs in the kernel related to cgroups, security is provided.
Saying containers shouldn't be used for security is like saying kernel functions shouldn't be used for security.
So, it can be exploited having access to the machine where docker is running and then using docker cp? can someone make a real use case of this bug?
The suggestion in the linked post is a situation where the Docker daemon is being controlled via its API in a multi-tennant environment where user configuration files are loaded into the container via the cp endpoint. I could concieve of this being a risk if you allow users to create symlinks in the location where the configuration files are situated.
because it's easy to do something such as :
$ docker run -it -v /:/hostfs debian chroot /hostfs
# I'm root !
This may be an unpopular opinion, but containers and Docker specifically shouldn't be used to isolate systems for security. It should be used to ease deployment.
In my opinion, VM's are less secure than containers. VM's provide a large attack surface, while one CAN restrict containers sufficiently. See contained.af. Doesnt mean Docker does this though.
Simply speaking, VMs only need to properly take care of a few privileged CPU opcodes.
Why don't people run containers in VM's? I don't get it, the only real selling point I can come up with for kernel level isolation is ability to over provision ram. And you shouldn't do that on a server anyways. It's perfectly possible to fire up a regular docker container inside KVM or whatever. With constant container security issues, why isn't this the norm?