1. 26

  2. 9

    Apropos nothing and everything, running a web app in chroot makes any number of filesystem traversal bugs a lot less interesting. It’s a bit more complicated on Windows, but nothing a decent installer couldn’t do for you.

    1. 6

      Just remember kids, chroot is not a security feature!

      You will be better off by making sure the permissions on all your files are right, and then writing a good selinux policy, and then ensuring your system is properly hardened (but not with chroots because they’re a hardening feature and not a security feature). Otherwise the false sense of security granted by your chroot will make you less secure and an unpatched Linux kernel vulnerability will let this script kiddie get root and escape the chroot anyway!

      Red Phat knows!

      How about false sense of security in using selinux and file permissions? Nope, they’re perfect and after them, there’s no need for hardening features such as chroot? Forget all the mitigations as well? :)

      1. 3

        Thing is, most people I know disable SELinux because it’s a pain in the ass to use. Now, call them retards, call them slackers, whatever. You will never be able to convince them to waste one more minute of their precious time the moment SELinux gets in the way. The OpenBSD approach, security from within, really validates the use of chroots. And in the context of a general security concept, chroots are damn fine.

        SELinux has its place, and it’s powerful. However, given it’s optional security it’s useless for the masses.

        1. [Comment removed by author]

          1. 3

            Reading forum threads and openbsd-misc, it seems as though each platform offers different tools which can be used to accomplish similar results. Chroot provides file-system isolation, but that isn’t enough to be a security feature.

            In fact, there was also a fair amount of skepticism that any combination of these is sufficient to fully isolate evil code. Perfectly isolating bad code seems to be a very hard problem. But if you need to virtualize a filesystem for some functional reason, you can use chroot to do that.


            Jail really is nice, but you can accomplish the same thing when using chroot + systrace if you just want a single running service per virtual jail. You can make it even tighter then a jail. But ok, it is a lot of work, jails make it easy to implement virtual servers. It is a nice feature, but I don’t miss it on OpenBSD.


            Is there anything [in OpenBSD] comparable to FreeBSD jails (now)?

            There’s chroot of course. Jail itself has issues and some of them are described eg. here http://www.youtube.com/watch?v=JaVnNllZxn4


            Virtualization has its values, but neither -security- nor -isolation from all problems- are among them. And that is so, whether chroot, jail, virtual machine, or “hypervisor” solution is selected.


            virtual machines / Chroot / Jails are not adding additional security, nor platform isolation, though they do offer the appearance of it. Many people think they are getting these through virtualization, but …

            Edit: While I’m here, it’s also worth pointing out that systrace is known to be broken – it assumes atomicity of syscalls, but it’s possible to generate race conditions which break the security assurances. 4

            1. 2

              And while I’m here, it’s also worth pointing out that systrace is gone.

              Also gone (from the OpenBSD base system) are Apache and BIND, referred to in the fourth post you linked. What is not gone, however, is the practice of chrooting daemons.

              Why again would one want to do some kind of filesystem isolation for daemons, if not for security? Just for feelsgood soundsnice and lookspretty?

              Lots and lots of people are arguing terminology these days, huh. That’s a hardening feature, not a security feature! Oh that’s just isolation, nothing to do with security. Oh and that is just a mitigation, again not a security feature…

              Features like the one in ImageMagick (publicized last night) look a lot less scary when the daemon using that library is chrooted, preferrably into an empty directory with not even a shell. Same for directory traversal features like the one in the linked article..

              1. 1

                Thanks for the fact-check.

                I suppose it does all come down to semantics but it’s still important to address. Chrooting daemons is an extra layer of security/hardening/mitigation, yes. But it’s important that people understand chroot+whatever isn’t enough to protect yourself from running evil code on your machine.

                We don’t chroot daemons because we think they’re evil. We chroot daemons to help mitigate problems/exploits.

                Sort of a case for seatbelts rather than silver-bullets.

                1. 1

                  Then what is enough to protect ourselves from running evil code?

                  1. 1

                    As far as I can tell, there is no “set and forget” way to solve this problem.

                    Over the past couple years, my approach has changed from blacklisting what’s broken, to whitelisting what’s safe. NoScript in the browser, and I’m working on installing OpenBSD on my Libreboot laptop (tricky because UEFI support is so new).

                    OpenBSD has my favorite approach. Continual auditing of the codebase, and they’re always implementing new ‘seatbelts’, such as ASLR, W^X, and now pledge(2). These seatbelts are used liberally – even in programs that you theoretically shouldn’t need protection from, such as the system-provided implementation of cat.

                    Theo has some great comments on magical “silver-bullet” thinking about security. In this case, specifically about the security of VMs (2007, so pretty dated now):

                    x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

                    You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

                    Harsh, but not inaccurate. And it’s part of the reason I’d rather use OpenBSD than QubesOS.

                    Eight years later, a critical vulnerability in Xen affected the security of QubesOS, and the developers were shocked, shocked!

                    It is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again (assert-like mechanisms perhaps?). Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work.

            2. 1

              This is roughly with FreeBSD Jails offer you. Heavier weight than a chroot, but with ZFS creating one is very cheap and tools like ezjail-admin and iocage do all the leg work for you.

            3. 3

              Caution: sarcasm.

              1. 1

                Thanks. Touch and go there for a moment with Poe’s Law.

          2. 4

            I always cringe when customers ask for reviews of WP sites, because there is inevitably something broken about their installation. A friend of mine, Larry Cashdollar, has discovered over 1300 WordPress plugin vulnerabilities. He and I have talked about setting up complete mechanisation to find more, because some of the things he’s found are trivial, and easy to scan for.

            Plugins aside, even the configuration is non-trivial to get correct, and if you’re not used to configuring WP, it can be… interesting… to get things correct. I know it’s gotten better, but still… so many problems.