Containers/jails draw the isolation boundary around your processes, whilst this technology confines your code within a singe process and completely isolates it from the system.
Further from being a different abstraction, container technologies (at-least in their current implementations of 'chroot on nukes') are not completely sealed or 'secure'. OpenVZ seems to be the most secured one over-there, requires kernel-patching and still... close but not 100% airtight. That is one of the reasons that many lightweight containers are used only as secondary sandbox (like Heroku) and not allowing you to run arbitrary C/assembly inside your environment. So, practically, LXC always ends up as secure-python-environment or ruby-environment as so on... never as secure x86 execution environment.
dotCloud (http://dotcloud.com) supports arbitrary code execution inside LXC containers (pre-2010 versions used OpenVZ, and very early versions were built on V-server). The main limitation is that the process runs under an unprivileged uid under a kernel managed and deployed by dotCloud.
I agree with the assessment that containers are not "completely secure" - I would not trust it to contain a root-privileged process. However an unprivileged process running inside an lxc container on a recent kernel will have an extremely hard time escaping.
What if I DoS attack some syscall? Or create zillions of files with 1 byte size driving crazy file-system or anything else.
Kernel is such vast area vulnerable for an attack that it is scary even to think about securing all of it and not leaving a single weak point. Moreover, you will screw your syscall API to the point that it will become unusable. At bare least we need standard for the syscall capping and etc... so programmer will know what to expect.
And thanks for the link, will check them and what solution they use and whether they are happy with it.
