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.
Which is only useful if they actually provide security.
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.
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...
Meanwhile, with Docker (including CVE-2019-5736, which allows for overwriting runc on the host system):
* 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?