3 ms·

While I have nothing against SELinux, I feel that modern solutions using containers have made it almost irrelivant. And now some SE supporters are fighting bac

While I have nothing against SELinux, I feel that modern solutions using containers have made it almost irrelivant. And now some SE supporters are fighting back in the dirtiest way possible. https://opensource.com/business/14/7/docker-security-selinux https://opensource.com/business/14/7/docker-security-selinux Mr. Walsh makes all sorts of claims about things, such as devices, which are never exposed to the container, not being namespaced. It is very bad when someone who is respected and has qualifications goes and spreads lies and insinuations, just because their product is no longer relevant.

tjohns 10y ago
I thought that Docker containers were primarily intended for environment isolation, not for security? As I understood it, Docker relies on the kernel enforcing syscall namespaces for security... and that there's a (admittedly small) possibility of container breakouts via this route, because of the large surface area involved. Even the Docker devs have a whitepaper that recommends running Docker inside a VM when multi-tenancy is involved, as part of a defence-in-depth strategy: https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Se...
- timthelion 10y ago
  The surface area for both technologies is the same: The kernel. Howerver, SELinux uses a complex set of rules for determining access rights, while containers use basic bindmounts.
- cyphar 10y ago
  Docker uses SELinux, seccomp and apparmour as well as stock Linux capabilities (in conjunction with namespaces) to reduce the attack surface exposed to a container. There's nothing inherently insecure about containers (look at FreeBSD and Solaris). The issues you see with Linux "containers" are usually caused by leaky abstractions (namespaces that don't namespace the entire kernel) and insufficiently clever setup scripts. But it is getting better.
- raesene6 10y ago
  One thing to watch out for when reading anything about container/Docker security is the date of the advice. that paper is from March last year, and there have been a lot of improvements to Docker security since then. Docker makes use of namespaces/capabilities/cgroups and syscall filtering by default and you can add apparmour or SELinux policies on top if you like. So the attack surface of a running docker container very much depends on how you've configured it. It's likely still larger than a VM Hypervisor, but I know that there are large organisations using containers for multi-tenancy, so I guess some people are ok with that kind of configuration...
fl0wenol 10y ago
The issue is that local privilege escalation to root will always be a thing, even with seccomp limiting syscalls visible in a container. sVirt (SELinux as it relates to VMs and containers) can make sure that even with unintended root escalation you don't touch what you weren't intending to touch. Full virtualization is preferred if this is a concern, trading off some overhead for increased isolation. But if the performance margins are thin for your containers (thus motivating the expected use of newer syscalls with increased likelihood of undiscovered/undisclosed escalations) and you're running something potentially adversarial, then take advantage of sVirt as a second layer.

tjohns 10y ago

I thought that Docker containers were primarily intended for environment isolation, not for security? As I understood it, Docker relies on the kernel enforcing syscall namespaces for security... and that there's a (admittedly small) possibility of container breakouts via this route, because of the large surface area involved. Even the Docker devs have a whitepaper that recommends running Docker inside a VM when multi-tenancy is involved, as part of a defence-in-depth strategy: https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Se...

timthelion 10y ago
The surface area for both technologies is the same: The kernel. Howerver, SELinux uses a complex set of rules for determining access rights, while containers use basic bindmounts.
cyphar 10y ago
Docker uses SELinux, seccomp and apparmour as well as stock Linux capabilities (in conjunction with namespaces) to reduce the attack surface exposed to a container. There's nothing inherently insecure about containers (look at FreeBSD and Solaris). The issues you see with Linux "containers" are usually caused by leaky abstractions (namespaces that don't namespace the entire kernel) and insufficiently clever setup scripts. But it is getting better.
raesene6 10y ago
One thing to watch out for when reading anything about container/Docker security is the date of the advice. that paper is from March last year, and there have been a lot of improvements to Docker security since then. Docker makes use of namespaces/capabilities/cgroups and syscall filtering by default and you can add apparmour or SELinux policies on top if you like. So the attack surface of a running docker container very much depends on how you've configured it. It's likely still larger than a VM Hypervisor, but I know that there are large organisations using containers for multi-tenancy, so I guess some people are ok with that kind of configuration...

fl0wenol 10y ago

The issue is that local privilege escalation to root will always be a thing, even with seccomp limiting syscalls visible in a container. sVirt (SELinux as it relates to VMs and containers) can make sure that even with unintended root escalation you don't touch what you weren't intending to touch. Full virtualization is preferred if this is a concern, trading off some overhead for increased isolation. But if the performance margins are thin for your containers (thus motivating the expected use of newer syscalls with increased likelihood of undiscovered/undisclosed escalations) and you're running something potentially adversarial, then take advantage of sVirt as a second layer.