32 ms·

Any notable downsides to using chroots?

rotten 7y ago
1) There were/are sometimes ways to break out of them. 2) The process table is mixed in with your OS process table - making it hard to tell what is running chrooted and what isn't. 3) The network stack is shared 4) They share an OS You can make a "spectrum" of environments where you run code. One one side is everything running on a single server in a single OS, on the right is everything having its own machine and OS. In between you have chroot, docker, blade servers, virtual machines, and other isolation techniques. chroot falls somewhere between everything running in one system, and everything running in docker containers on one system.
- organsnyder 7y ago
  I'm curious as to why blade servers are in your mix—aren't they essentially separate physical machines sharing a common backplane for I/O? Seems basically identical (from a software perspective) as servers hosted in the same rack.
  - kbenson 7y ago
    They also often share power among some number of blades. When the spectrum is how co aolidated software and hardware are, it is a bit apart from separate physical instances, as the fault tolerance isn't quite the same.
  - linuxdude314 7y ago
    Blade servers are purchased for their density.
- seba_dos1 7y ago
  1) should actually be "there are ways to break out of them, period". chroot isn't a security feature, it doesn't even try to be one.
  - crdrost 7y ago
    This. If you want the security features, switch to a BSD (jails) or illumos (zones). These started spiritually from that same chroot place but were designed to incarcerate your software in a small subsystem. The illumos ecosystem in particular got a lot of work from Joyent in this container vein—like how Windows can now run Linux binaries natively because they implemented the Linux system call table, illumos has Linux-branded zones that do the same “our kernel, Linux’s API, no virtualization” approach to Linux containers.
    - Spivak 7y ago
      I mean you should throw in Linux filesystem namespaces in there too since I doubt too many people can just switch to a BSD for this.
    - ncmncm 7y ago
      Windows runs Linux binaries by running Linux in a VM. Something newish is that Windows also implements Windows by running NT and a Windows UI in a VM. Running on a hypervisor originated at IBM, on its 370, and is very mature technology. Arguably, an OS running on bare metal is practically an embedded system, these days; There are just so many things that make a hypervisor useful or essential. The key insight IBM had was that the hypervisor runs under the control of one of its VMs. That means the hypervisor doesn't need to provide a full-featured, comfortable work environment; that is the job of guest OSes. Instead, it manages resources according to policies implemented in an "executive" guest OS not used for, or vulnerable to mistakes or malevolence in, regular user programs. A modern example of such a system is Qubes, security-oriented OS that hosts and orchestrates Linux, BSD, and even Windows VMs.
      - JonathonW 7y ago
        WSL 2 is virtualization-based (and likely Microsoft’s primary path going forward), but WSL 1 was not— it actually did implement the Linux ABI on top of the Windows kernel, allowing Linux processes to coexist alongside Windows processes (with no actual Linux kernel involved at any point). It’s actually a pretty neat architecture— I’m on my phone right now and can’t track down a link, but it’s worth reading about if you’ve got the time. Kind of a shame that they moved on to the virtualization approach, but understandable— they’re trying to solve the same sort of problem as Wine, where you’ve got to mimic all the quirks of a foreign OS and it’s also a moving target (so you’re never “done”).
- war1025 7y ago
  > The process table is mixed in with your OS process table Just wanted to point out that this is true for Docker containers as well. Something that has actually come in handy from time to time trying to diagnose things. I think from within the container you can only see that container's processes, but outside (as root) you can see all processes, even those inside the container.
  - floren 7y ago
    It makes it easy to attach a debugger, too.
  - danielhlockard 7y ago
    That's correct.
- linkdd 7y ago
  > 4) They share an OS Unless you make your Dockerfiles `FROM scratch` you do have an OS too.
air7 7y ago
https://en.wikipedia.org/wiki/Chroot#Limitations https://en.wikipedia.org/wiki/Chroot#Limitations
e12e 7y ago
Apart from other comments same pro/con as containers: I seem to recall we had a commercial backup solution that ran like this - as suid root. And came with some quite outdated dependencies. Vulnerabilities in libc (eg: dns resolver) bundled Sendmail, databases... They can be independently patched (good) or they can be independently left on ancient unpatched versions (bad). If you use the system/distro library services, it can be easier to verify patch levels and know if any given hole (eg this week's sudo hole) affect your system or not.

1) There were/are sometimes ways to break out of them. 2) The process table is mixed in with your OS process table - making it hard to tell what is running chrooted and what isn't. 3) The network stack is shared 4) They share an OS You can make a "spectrum" of environments where you run code. One one side is everything running on a single server in a single OS, on the right is everything having its own machine and OS. In between you have chroot, docker, blade servers, virtual machines, and other isolation techniques. chroot falls somewhere between everything running in one system, and everything running in docker containers on one system.

organsnyder 7y ago
I'm curious as to why blade servers are in your mix—aren't they essentially separate physical machines sharing a common backplane for I/O? Seems basically identical (from a software perspective) as servers hosted in the same rack.
- kbenson 7y ago
  They also often share power among some number of blades. When the spectrum is how co aolidated software and hardware are, it is a bit apart from separate physical instances, as the fault tolerance isn't quite the same.
- linuxdude314 7y ago
  Blade servers are purchased for their density.
seba_dos1 7y ago
1) should actually be "there are ways to break out of them, period". chroot isn't a security feature, it doesn't even try to be one.
- crdrost 7y ago
  This. If you want the security features, switch to a BSD (jails) or illumos (zones). These started spiritually from that same chroot place but were designed to incarcerate your software in a small subsystem. The illumos ecosystem in particular got a lot of work from Joyent in this container vein—like how Windows can now run Linux binaries natively because they implemented the Linux system call table, illumos has Linux-branded zones that do the same “our kernel, Linux’s API, no virtualization” approach to Linux containers.
  - Spivak 7y ago
    I mean you should throw in Linux filesystem namespaces in there too since I doubt too many people can just switch to a BSD for this.
  - ncmncm 7y ago
    Windows runs Linux binaries by running Linux in a VM. Something newish is that Windows also implements Windows by running NT and a Windows UI in a VM. Running on a hypervisor originated at IBM, on its 370, and is very mature technology. Arguably, an OS running on bare metal is practically an embedded system, these days; There are just so many things that make a hypervisor useful or essential. The key insight IBM had was that the hypervisor runs under the control of one of its VMs. That means the hypervisor doesn't need to provide a full-featured, comfortable work environment; that is the job of guest OSes. Instead, it manages resources according to policies implemented in an "executive" guest OS not used for, or vulnerable to mistakes or malevolence in, regular user programs. A modern example of such a system is Qubes, security-oriented OS that hosts and orchestrates Linux, BSD, and even Windows VMs.
    - JonathonW 7y ago
      WSL 2 is virtualization-based (and likely Microsoft’s primary path going forward), but WSL 1 was not— it actually did implement the Linux ABI on top of the Windows kernel, allowing Linux processes to coexist alongside Windows processes (with no actual Linux kernel involved at any point). It’s actually a pretty neat architecture— I’m on my phone right now and can’t track down a link, but it’s worth reading about if you’ve got the time. Kind of a shame that they moved on to the virtualization approach, but understandable— they’re trying to solve the same sort of problem as Wine, where you’ve got to mimic all the quirks of a foreign OS and it’s also a moving target (so you’re never “done”).
war1025 7y ago
> The process table is mixed in with your OS process table Just wanted to point out that this is true for Docker containers as well. Something that has actually come in handy from time to time trying to diagnose things. I think from within the container you can only see that container's processes, but outside (as root) you can see all processes, even those inside the container.
- floren 7y ago
  It makes it easy to attach a debugger, too.
- danielhlockard 7y ago
  That's correct.
linkdd 7y ago
> 4) They share an OS Unless you make your Dockerfiles `FROM scratch` you do have an OS too.

air7 7y ago

https://en.wikipedia.org/wiki/Chroot#Limitations https://en.wikipedia.org/wiki/Chroot#Limitations

e12e 7y ago

Apart from other comments same pro/con as containers: I seem to recall we had a commercial backup solution that ran like this - as suid root. And came with some quite outdated dependencies. Vulnerabilities in libc (eg: dns resolver) bundled Sendmail, databases... They can be independently patched (good) or they can be independently left on ancient unpatched versions (bad). If you use the system/distro library services, it can be easier to verify patch levels and know if any given hole (eg this week's sudo hole) affect your system or not.