2 ms·

> 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security a

> 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work. If the container system designers did their job properly it won't matter what the software does inside of it, as breakouts shouldn't be possible. It has been a few years since I looked, but last time I checked there hasn't been a vulnerability in FreeBSD's jails code that allowed someone to break out. The closest to it was an issue with devfs that allowed 'tunnelling' out, but not with the actual Jails code itself: * https://www.freebsd.org/security/advisories/FreeBSD-SA-14:07.devfs.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-14:07... Meanwhile, with Docker (including CVE-2019-5736, which allows for overwriting runc on the host system): * https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html https://www.cvedetails.com/vulnerability-list/vendor_id-1353... > 2. There is a nuanced, different interface between software-system and container-system One keeps things inside and other other often doesn't?

ethbr0 5y ago
One side has a huge footprint to secure (software-system), because it's every way software could ever need to interact with a local system. The other can expose a much smaller one (container-system), because it only needs to include things one would have gone off-local-machine for (i.e. networking). So from a security boundary, containers are basically a machine-internal firewall between programs and the host.
- throw0101a 5y ago
  > So from a security boundary, containers are basically a machine-internal firewall between programs and the host. Which is only useful if they actually provide security.
  - ethbr0 5y ago
    You're missing my point. It's effectively impossible to ever provide security at the program-system interface, due to the surface area. (I.e. the SELinux problem) The very concept of having a container (that internally simulates a system) creates fundamentally different opportunities that allow both (programs that work) and (security). Whinging about whether or not current containers do a good or bad job of it is a less interesting, short term quibble.

ethbr0 5y ago

One side has a huge footprint to secure (software-system), because it's every way software could ever need to interact with a local system. The other can expose a much smaller one (container-system), because it only needs to include things one would have gone off-local-machine for (i.e. networking). So from a security boundary, containers are basically a machine-internal firewall between programs and the host.

throw0101a 5y ago
> So from a security boundary, containers are basically a machine-internal firewall between programs and the host. Which is only useful if they actually provide security.
- ethbr0 5y ago
  You're missing my point. It's effectively impossible to ever provide security at the program-system interface, due to the surface area. (I.e. the SELinux problem) The very concept of having a container (that internally simulates a system) creates fundamentally different opportunities that allow both (programs that work) and (security). Whinging about whether or not current containers do a good or bad job of it is a less interesting, short term quibble.