4 ms·

> Only FreeBSD has jails, but it's not quite the same thing. Jails are more like containers. The evolution of the chroot concept on OpenBSD is pledge. On Linux

by cyphar 10y ago

> Only FreeBSD has jails, but it's not quite the same thing. Jails are more like containers. The evolution of the chroot concept on OpenBSD is pledge. On Linux it's seccomp. > runC creates Linux containers. Containers and VMs are not security solutions, rather system administration and provisioning solutions. As someone who maintains runC, I disagree with you quite vehemently. Containers are a security system. Yes, they've had their fair share of problems but that doesn't mean that > chroot() was originally implemented as a type of container. It allowed you to run programs (especially before the adoption of dynamic linking) from a private directory tree when building, installing, and testing software, without risking overwriting the real system. Basically, it's purpose was just like Docker. That is a very narrow view of what the purpose of containers is. > But the use of chroot() as a security solution is different. You don't usually mount /dev or /proc in a chroot jail as that would defeat the purpose. That's not correct. Many programs require /proc, /dev or /sys to function. Most of the uses I've seen of chroot do mount stuff like that in the rootfs. If you're an unprivileged user you haven't really increased the attack surface. And even if you don't mount those filesystems, chroot doesn't namespace networking or process trees -- so those avenues of attack still exist. That _alone_ makes containers more secure than chroot. > Containers don't reduce code surface area at all, not to the kernel, nor usually to stock SUID and SGID binaries. All the same devices files _and_ system calls are still available, as well as typical SUID account and system management binaries. This is not necessarily true, given the existence of no_new_privs, seccomp and user namespaces in Linux. Not to mention that all of the runtimes I know of do not just mount /dev (instead it's a tmpfs with bindmounts for the devices needed by containers). And not to mention that chroot is just a weaker version of mount namespaces (which is a far more powerful primitive for isolating processes). > But that's no different than chroot, and so it's not really an improvement over chroot in that sense. More importantly, the code implementing Linux containers is complex and has opened up far more kernel bugs than it's closed. That's just FUD. Yes, the way Linux went about creating namespaces wasn't the best way, but modern Linux containers are more secure than chroot. Chroot doesn't even protect against messing around with other processes on your host system! It doesn't protect against accessing things outside of your current root (pivot_root actually fixes that problem -- but you can't use it without using mount namespaces).

wahern 10y ago
Mount namespaces and user namespaces have been a ripe area for Linux exploits. Many of the local privilege escalation exploits published since the shift to containers involved this code--either bugs in the code or because of unexpected, unintended consequences. The reason why only root can call chroot is because the ability to change the namespace can cause havoc with other privileged code not expecting the namespace to be mutable in certain critical respects. chroot originally didn't require root permissions, but then people figured out all the security problems it caused in the Unix privilege model. And because it was so difficult to fix comprehensively given that model, the solution adopted was to limit it to root. That difficulty is why more sophisticated and malleable namespace solutions were avoided for so long. And the recent history of exploits in Linux has only proven the original wisdom of that. Adding more complexity and degrees of freedom to namespaces (the ability to create isolated namespaces) only exacerbates those problems. And it's triply stupid to allow non-root users to manipulate namespaces like that, which is what Linus finally allowed and which some Linux distributions began allowing by default before more exploits were published. It's an approach that makes sense in many other contexts, but not in the context of the Unix process and privilege model. It works very well in Plan 9, but Plan 9 was carefully designed to avoid the same design decisions in Unix that make mutable namespaces so problematic. seccomp doesn't save containers. It has zero to do with containers. It's a simple mechanism to limit syscalls by syscall number. In an abstract sense that's a namespace related issue (syscalls are in a shared namespace, and syscall numbers are paths into that namespace), but it's a real stretch to see that as a facet of containerization. Containers can help people develop security solutions. I won't dispute that. They're a tool, just not one that is usefully scene as a principally security tool. Regarding PID namespacing and signaling, that's just FUD about chroot jails. The PID namespace is indeed unaffected by chroot, but in a chroot jail you setuid to an unprivileged user. That's part of the protocol of a chroot _jail_. An unprivileged user cannot directly send signals to other processes without the same UID. On systems like OpenBSD every service is assigned a unique UID. On Linux the nobody user is too often abused, but major services like databases are still usually assigned a unique UID and so cannot be signaled by a chroot-jailed, unprivileged process. It's even possible to assign random UIDs to processes (e.g. among slave processes), as the kernel doesn't care what the integer value is as long it fits within some predefined range. The chroot jail protocol is hackish, but I can't recall a bug in Linux or any other Unix that permitted an unprivileged user process to directly signal processes of a different user. Nor can I recall a bug in kernel chroot implementations that violated the defined semantics, at least not where Linux's new namespacing features weren't involved. Given the reality of security issues on modern systems--that kernels are so complex that there's an endless bounty of exploits at the user-kernel interface, the chroot jail is a singularly simple and effective solution that addresses that problem, at least before pledge, seccomp, and capsicum came onto the scene.

by cyphar 10y ago

wahern 10y ago

Mount namespaces and user namespaces have been a ripe area for Linux exploits. Many of the local privilege escalation exploits published since the shift to containers involved this code--either bugs in the code or because of unexpected, unintended consequences. The reason why only root can call chroot is because the ability to change the namespace can cause havoc with other privileged code not expecting the namespace to be mutable in certain critical respects. chroot originally didn't require root permissions, but then people figured out all the security problems it caused in the Unix privilege model. And because it was so difficult to fix comprehensively given that model, the solution adopted was to limit it to root. That difficulty is why more sophisticated and malleable namespace solutions were avoided for so long. And the recent history of exploits in Linux has only proven the original wisdom of that. Adding more complexity and degrees of freedom to namespaces (the ability to create isolated namespaces) only exacerbates those problems. And it's triply stupid to allow non-root users to manipulate namespaces like that, which is what Linus finally allowed and which some Linux distributions began allowing by default before more exploits were published. It's an approach that makes sense in many other contexts, but not in the context of the Unix process and privilege model. It works very well in Plan 9, but Plan 9 was carefully designed to avoid the same design decisions in Unix that make mutable namespaces so problematic. seccomp doesn't save containers. It has zero to do with containers. It's a simple mechanism to limit syscalls by syscall number. In an abstract sense that's a namespace related issue (syscalls are in a shared namespace, and syscall numbers are paths into that namespace), but it's a real stretch to see that as a facet of containerization. Containers can help people develop security solutions. I won't dispute that. They're a tool, just not one that is usefully scene as a principally security tool. Regarding PID namespacing and signaling, that's just FUD about chroot jails. The PID namespace is indeed unaffected by chroot, but in a chroot jail you setuid to an unprivileged user. That's part of the protocol of a chroot _jail_. An unprivileged user cannot directly send signals to other processes without the same UID. On systems like OpenBSD every service is assigned a unique UID. On Linux the nobody user is too often abused, but major services like databases are still usually assigned a unique UID and so cannot be signaled by a chroot-jailed, unprivileged process. It's even possible to assign random UIDs to processes (e.g. among slave processes), as the kernel doesn't care what the integer value is as long it fits within some predefined range. The chroot jail protocol is hackish, but I can't recall a bug in Linux or any other Unix that permitted an unprivileged user process to directly signal processes of a different user. Nor can I recall a bug in kernel chroot implementations that violated the defined semantics, at least not where Linux's new namespacing features weren't involved. Given the reality of security issues on modern systems--that kernels are so complex that there's an endless bounty of exploits at the user-kernel interface, the chroot jail is a singularly simple and effective solution that addresses that problem, at least before pledge, seccomp, and capsicum came onto the scene.