On Tue, Dec 4, 2012 at 7:42 PM, Robert Elz <k...@munnari.oz.au> wrote: > Even chroot isn't a problem, unless you're tempted to view it as some > kind of security mechanism. It really isn't > ... > If true compartmentalisation is wanted for security purposes, we would > need something approaching true VM (like Xen DomU's or whatever) where > the whole environment can be protected, not just the filesystem. > > chroot provides no protection at all to processes killing others, > reconfiguring the network, binding to random ports, thrashing the CPU, > altering sysctl data, rebooting the system, ... There's almost no end > to the harm that a sufficiently inspired (and privileged) rogue process > can do, even if it is running in a chroot.
Personally, I don't see anything fundamentally wrong in treating chroot as a foundation for security tool. It's true that by itself it is not a security tool and never has been but it can easily be hardened with a help of KAUTH_CRED_CHROOT which is now in the kernel and standard kauth(9) mechanisms. An year and a half ago I proposed new security model for it. http://mail-index.netbsd.org/tech-kern/2011/07/09/msg010903.html Of course it cannot replace "virtualization" techniques like Xen or Linux's OpenVZ/cgroups because it doesn't provide efficient resource management but as a security tool hardened chroot may be just good enough. Especially if we take into account how easely daemons can be configured for running inside chroot in rc.d. On the other hand if we generalize improvements of fchdir(2) and fchroot(2) (I mean EPERM if the current working directory is not at or under the new root directory), that is reimplement them with a help of kauth(9) we will be able to do the same for fexecve(2). All in all, unless I miss something I don't see serious contradictions between chroot and kexecve.
