28 ms·

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 chro

• 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”).
  • xorcist 7y ago
    The "chroots doesn't offer any security" statement needs to be a bit more nuanced. A non-privileged process in a dedicated directory can't do much damage, and certainly can't escape the chroot without some sort of privilege escalation. That does not mean you can slap chroot syscalls everywhere and call it secure, of course. But it is still an important part of dropping privileges, together with seccomp-bpf, control groups and the various ACL systems. It is an important part of things like the OpenSSH privilege separation, where the early protocol is handled by a dedicated process in a read only chroot. It proven both simple and effective in practice, contrary to the idea that chroots are escapable.
    • viraptor 7y ago
      Here's a list of ways to break out, marked either as root required or not. Some are only vague idea, others are explained. https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break%20Out_from_Various_Chroot_Solutions_-_Bucsay_Balazs.pdf https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break%20O... I too thought you can't easily escape unprivileged chroot, but in reality you need to think about quite a few things to make sure it's true. And once you need to think about those things... Why not apparmor/selinux instead.
      • xorcist 7y ago
        None of the listed methods are novel. Most are elaborate ways of saying "privilege escalation". If an untrusted process can escalate to root, ptrace to unrelated processes, or access memory outside your process, it was never really contained in the first place. Do also note that none of the listed methods works in what the presentation itself calls a "reasonable chroot". > Why not apparmor/selinux instead It's not either or. Dropping privileges is something you preferably do in more ways than one.
• 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.