[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110814120448.GA15372@openwall.com>
Date: Sun, 14 Aug 2011 16:04:48 +0400
From: Solar Designer <solar@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Cc: Chris Evans <scarybeasts@...il.com>, djm@...drot.org
Subject: Re: 32/64 bitness restriction for pid namespace
Vasiliy,
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).
> > OK, you don't have to emulate the exact same behavior. Maybe ENOSYS
> > like you implemented initially would be fine.
>
> Hmm, so you say such emulation is not needed?
I was hoping it'd be simpler, but if it turns out to be non-trivial,
then you can drop it.
And I agree that SIGKILL would be slightly better than -ENOSYS.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
