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 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.
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.
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).
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 :(
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"
16 comments
[ 3.9 ms ] story [ 38.1 ms ] threadunix -> unixen
emacs -> emacsen
https://lwn.net/Articles/252794/
which links to here:
http://web.archive.org/web/20071011110715/http://kerneltrap....
which further makes the point that chroot is not now and has never been a member of the "security tool" universe.
AIUI, containers are meant to be secure against processes (and, therefore, users) that want to get out, so if you care about that, use those, instead.
containers that run as root are no more secure than chroot..
( see : docker )
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.
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.
Solaris, in particular, offers a far superior solution with zones.
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).
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"
* -5 / error, "error creating $nestdir"
* -6 / not tested
* -7 / error, "error attaching process"
* -9 / no error, root still inside container