Re: [kernel-hardening] 32/64 bitness restriction for pid namespace

[Vasiliy Kulikov <segoon@openwall.com>]

Solar,

On Sun, Aug 14, 2011 at 16:04 +0400, Solar Designer wrote:
> On Sun, Aug 14, 2011 at 03:55:50PM +0400, Vasiliy Kulikov wrote:
> > Btw, it can be even simplier.  If we use only one flag - lock to the
> > current bitness - then the code is greatly simplified.  The same
> > behaviour as with 3 flags can be achieved with binary helpers:
> 
> I dislike this.  Please implement extra flags instead.
> 
> > 1) vzctl wants to create CT 101 with specific bitness.  If it is 64, it
> > simply calls prctl(LOCK_BITNESS) and execve's init.  If it is 32, it
> > exec's small 32 bit helper binary that does the same job, but as 32
> > bits.  It is compiled from the same source files, so the helper creation
> > process is trivial.
> 
> I'd rather have a few extra lines of code in the kernel.
> 
> > 2) vzctl wants to create CT 101 with the bitness its /sbin/init is.
> > Then it just looks at /sbin/init and does (1) steps.
> 
> "Looking at" /sbin/init (checking the ELF header?) sounds risky to me.
> This depends on when vzctl does that, though (what privileges it still
> has at that point).

Then probably we don't need "lock to any bitness on exec" at all?  Only
explicit settings in vz config file.  Configs are anyway dependant on
the contained in the container distro.  The setup will happen only once
(at the container setup), but this way of handling removes some code
from the kernel critical pathes.

What's the global role of "lock to any bitness on exec"?  I can see only
one significant case - have one generic config for containers, which
doesn't depend on the bitness.  But then it is still needs some manual
changes because of the CT root compromize threat (unless we don't think
about CT root compromize, only CT daemons/users compromize).

Thanks,

-- 
Vasiliy