4 ms·

> The evolution of the chroot concept on OpenBSD is pledge. I think that's a dangerous way to look at it, and thinking of some named thing as a "solution" to m

by clarry 10y ago

> The evolution of the chroot concept on OpenBSD is pledge. I think that's a dangerous way to look at it, and thinking of some named thing as a "solution" to making shit secure is exactly the kind of thinking that led people to treat chroot as a "jail" or "sandbox" and then be surprised that it doesn't actually contain their malicious process that runs as root and has access to various system resources. Pledge does one thing, chroot does another thing, unix users and permissions do yet another thing, pf the firewall does its own thing, and exploit mitigations do yet another thing. Doing privilege separation right will help you get most out them all. If we wanted to view pledge as an evolution of something, that something would probably be systrace; both exist to restrict syscalls, and both exist(ed) on OpenBSD, but the design of pledge is quite different. These are features that complement each other, and the more your applications employ them, the better off they are. None of them is supposed to be a single-switch solution that says "make this process secure". It's doesn't work that way, and it can't work that way. For instance, if you try to use chroot without privsep, it is quite likely that you end up having to mount things or add libraries and binaries or other files under the chroot, which does carry obvious risks. On the other hand, when it's done well, the use of chroot in a privsep'd process is invisible to the user, and there is no need to build a "mini-system" inside the chroot. Unfortunately it never seemed to be a particularly popular in the Linux world where everyone seems to be thinking "sandbox" or something more complicated. So when people say that most uses of chroot they've seen requires mounting /proc or doing other dangerous stuff in a chroot, they've probably just not noticed the quite-a-few uses of chroot that happen automatically under the hood...

wahern 10y ago
I agree that they complement each other. Pledge isn't an evolution of chroot, it's an evolution of chroot jails. And I meant evolution in the sense of continuing the approach of implementation centric, non-policy-based security limits orchestrated by the developer, not the system administrator in terms of access to logical resources. Capsicum is also similar in that respect. And I meant solution in the sense that it's a solution to limiting namespace visibility and visibility of vulnerable software interfaces. It's not a security "solution" in the sense of it guarantees, on its own complete safety. Security is a process, not a product. But in distinction to containers it is a security solution, just like a gun is a self-defense solution. Whereas containers are no more a security solution than metallurgy is a self-defensive solution. A container by itself doesn't limit anything, where as a chroot jail, however imperfectly done, does create a concrete a defensive posture by its very nature. Just like ASLR despite ROP attacks. I should have been more careful in making those distinctions. It's especially important because chroot jails are something of a hack given the origin and original purpose of the chroot syscall, which leaves it open to lazy criticism. But it's still an effective hack as far as its limits go. Criticisms of chroot jails, and discussion of exploits, usually boil down to not properly creating the chroot jail, not because there's no way to ever create the chroot. That it can be difficult to create the jail properly and to keep from breaking it later on as an application becomes more complex, such as by accidentally keeping a directory descriptor open across the jail creation, or mounting /proc, is a valid criticism. But as you say it's not as difficult as people make it seem. Setting up seccomp jails isn't trivial, either. With chroot, seccomp, SELinux, and any security method it's always going to be the case that some innocuous-seeming capability or resource preserved out of convenience turned out to be a portal for breaking out of the jail. And convenience is always a concern, otherwise we'd always limit processes to nothing but read(2) and write(2), sort of like the original seccomp that few people could make practical use of.

by clarry 10y ago

wahern 10y ago

I agree that they complement each other. Pledge isn't an evolution of chroot, it's an evolution of chroot jails. And I meant evolution in the sense of continuing the approach of implementation centric, non-policy-based security limits orchestrated by the developer, not the system administrator in terms of access to logical resources. Capsicum is also similar in that respect. And I meant solution in the sense that it's a solution to limiting namespace visibility and visibility of vulnerable software interfaces. It's not a security "solution" in the sense of it guarantees, on its own complete safety. Security is a process, not a product. But in distinction to containers it is a security solution, just like a gun is a self-defense solution. Whereas containers are no more a security solution than metallurgy is a self-defensive solution. A container by itself doesn't limit anything, where as a chroot jail, however imperfectly done, does create a concrete a defensive posture by its very nature. Just like ASLR despite ROP attacks. I should have been more careful in making those distinctions. It's especially important because chroot jails are something of a hack given the origin and original purpose of the chroot syscall, which leaves it open to lazy criticism. But it's still an effective hack as far as its limits go. Criticisms of chroot jails, and discussion of exploits, usually boil down to not properly creating the chroot jail, not because there's no way to ever create the chroot. That it can be difficult to create the jail properly and to keep from breaking it later on as an application becomes more complex, such as by accidentally keeping a directory descriptor open across the jail creation, or mounting /proc, is a valid criticism. But as you say it's not as difficult as people make it seem. Setting up seccomp jails isn't trivial, either. With chroot, seccomp, SELinux, and any security method it's always going to be the case that some innocuous-seeming capability or resource preserved out of convenience turned out to be a portal for breaking out of the jail. And convenience is always a concern, otherwise we'd always limit processes to nothing but read(2) and write(2), sort of like the original seccomp that few people could make practical use of.