tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: core statement on fexecve, O_EXEC, and O_SEARCH






On Wed, Dec 5, 2012 at 6:17 AM, Aleksey Cheusov <cheusov%tut.by@localhost> wrote:
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

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.



Home | Main Index | Thread Index | Old Index