I think chroot can be used as one piece in a defense-in-depth security scheme.
I think it is incorrect to make a blanket statement that chroot cannot be used to increase security at all.
Further, I think all of the "root needed" exploits (most of them) are irrelevant. If you have root, who cares about defeating a chroot on that system ? You're already root.
Finally, I note that the systems I use chroot on (FreeBSD) have almost zero vulnerability (see table on slide 27).
I understand that the attack surface of a cgroup based container is bigger than a VM, but saying that just running processes as root in contains is not more secure than chroot begs at least for some reference.
I believe that "root is root" is just shorthand for...
If you aren't using unprivileged containers, then the only approach you have for making the container more secure than chroot is a whack-a-mole style approach.
By whack-a-mole, I mean trying to map out the attack surface, and using a hodge podge of tools to try and close them (kernel cap-drops, apparmor, se-linux, firewall rules, overlay mounts for /proc, /sys, etc).
I think it's reasonable to say that the whack-a-mole approach isn't truly more secure. In the same way that having a vault door on the front of your house, next to an open window isn't any more secure than having the door wide open.
I don't know if I'm using this tool incorrectly or if Docker containers contain any measures against what it tries.
On a machine running Linux 4.2.7 and a container created with Docker 1.9.1, the tool either failed with an error or said it had broken out but the root was still inside the container.
Modes / Result:
* -0 / no error, root still inside container
* -1 / no error, root still inside container
* -2 / no error, root still inside container
* -3 / error, "error mounting chroot: Operation not permitted"
* -4 / error, "error creating block device: No such file or directory"
Eh, this is sort of silly in some respects. chroot is not meant to be a security mechanism (yes, I know the presentation mentions this). The limitations are well known in the OS community. With that said, I agree that many developers mistake chroot's real purpose.
Solaris, in particular, offers a far superior solution with zones.
When I clicked this link, apparently SlideShare did some automatic voodoo with my LinkedIn cookie and now there's a public slideshare profile page with my name on it that I cannot delete or unpublish :(
Interestingly, I have never seen "emaces" suggested as a plural of emacs, despite emacs-era hackers' propensity to play with plurals (and other affixes).
I think it is incorrect to make a blanket statement that chroot cannot be used to increase security at all.
Further, I think all of the "root needed" exploits (most of them) are irrelevant. If you have root, who cares about defeating a chroot on that system ? You're already root.
Finally, I note that the systems I use chroot on (FreeBSD) have almost zero vulnerability (see table on slide 27).