3 ms·

Container break outs are rare and they typically require the attacker being able to control either the container creation parameters and/or the actual image bei

Container break outs are rare and they typically require the attacker being able to control either the container creation parameters and/or the actual image being run. If you control those things and apply process isolation best practices (seccomp, cap drops, etc) then you are in pretty good shape. Source: ran a container based RCE service that ran millions of arbitrary workloads per month. We had sophisticated network and system anomaly detection, high priced pentesters etc and never had a breakout.

justinclift 4y ago
> ... never had a breakout. Would "never detected a breakout" be better wording? :)
- ithkuil 4y ago
  > We had sophisticated network and system anomaly detection, high priced pentesters I assume GP wrote that in order to say that they have a high confidence that they never actually had a breakout. You are technically correct. But your logic applies to everything. Is the isolation provided by VMs good enough? Is airgapping enough to prevent breakout? There are many things that factor in when you decide what's reasonable. Some are first principle arguments (containers use the same kernel as the host, the kernel has a large surface area, ...). Others are statistical arguments: there have been past breakouts with this stack, it's thus reasonable to expect more in the future, ...
ithkuil 4y ago
Have you used things like gvisor?
adamgordonbell 4y ago
Interesting! What was the service? IN our case we control the container, which is BuildkitD, but it has to be run privileged, which means lots of solutions are off the table.
- ones_and_zeros 4y ago
  Rather not say. Yea building and then running containers where users get to pick the base image is a risk. We found that privileged is a pretty big hammer and thought we needed it too but we found ways to give us the functionality we needed without all the extra stuff we didn't need the privileged brings in.

justinclift 4y ago

> ... never had a breakout. Would "never detected a breakout" be better wording? :)

ithkuil 4y ago
> We had sophisticated network and system anomaly detection, high priced pentesters I assume GP wrote that in order to say that they have a high confidence that they never actually had a breakout. You are technically correct. But your logic applies to everything. Is the isolation provided by VMs good enough? Is airgapping enough to prevent breakout? There are many things that factor in when you decide what's reasonable. Some are first principle arguments (containers use the same kernel as the host, the kernel has a large surface area, ...). Others are statistical arguments: there have been past breakouts with this stack, it's thus reasonable to expect more in the future, ...

ithkuil 4y ago

Have you used things like gvisor?

adamgordonbell 4y ago

Interesting! What was the service? IN our case we control the container, which is BuildkitD, but it has to be run privileged, which means lots of solutions are off the table.

ones_and_zeros 4y ago
Rather not say. Yea building and then running containers where users get to pick the base image is a risk. We found that privileged is a pretty big hammer and thought we needed it too but we found ways to give us the functionality we needed without all the extra stuff we didn't need the privileged brings in.