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.