Re: core statement on fexecve, O_EXEC, and O_SEARCH

[Aleksey Cheusov <cheusov%tut.by@localhost>]

On Tue, Dec 4, 2012 at 7:42 PM, Robert Elz <kre%munnari.oz.au@localhost> 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.