On Wed, Dec 5, 2012 at 6:17 AM, Aleksey Cheusov <cheu...@tut.by> wrote:
> 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 > I'm going to agree with Aleksey and Thor here. Until we have a better mechanism in tree we should not be weakening chroot. In fact, we've actually made our chroot less POSIX compliant in order to strengthen it's security. To do otherwise would be like throwing away your only hammer because it was rusty. -=erik. > 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. >
