Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Jul 2012 21:13:48 +0400
From: Vasily Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: vzctl 3.3 && CPT

Hi,

On Thu, Jul 26, 2012 at 15:40 +0400, gremlin@...mlin.ru wrote:
> On 26-Jul-2012 15:04:05 +0400, Vasily Kulikov wrote:
>  > 3) stay at vzctl 3.0.23.
>  > I'm going with (3) now as it doesn't limit our future wishes.
>  > Forwardporting bitness patch will be rather simple, I guess.
> 
> I think the best solution is to stay at (3) while working on (2).

So, I've successfully backported bitness_lock patch to our RHEL6-based
kernel.  The patched vzctl seems to work on both i686 and x86_64
kernels (tested on trivial lock.c sample which I've posted at LKML
thread related to bitness_lock).

However:

1) The kernel patch should not limit bitness_lock functionality even if
we run 32-bit kernel (or 64-bit kernel without IA32_EMULATION support)
because the information about the locked bitness must present in cases
of CT migration.

E.g. if we run 64-bit container on 64-bit system with
CONFIG_IA32_EMULATION=y and a process inside of it locks itself with 64
bits, the lock must be still kept if we migrate it to a 64-bit system with
CONFIG_IA32_EMULATION=n and then migrate it back.

Also, one should be able to lock itself with 32 bits on 32-bit kernel
and then be migrated to 64-bit system.  The task must not be able to do
64-bit syscalls in this case.

FWIW, I haven't tested CPT functionality with bitness_lock, I'm sure it
is not ready for CPT yet.


2) My current vzctl patch is rather ugly.  lock_on_exec locks a task
only at the next execve(), but it disappears if execve(2) fails.  IOW,
execve("/no-such-binary")+execve("/bin/bash") doesn't lock the task.
So, vzctl must re-set this flag before each call to execve().  vzctl
uses deep calls from main() to actual execve(), so it is rather awkward
to explicitly pass "bitness_lock" argument through so many functions
(a structure with all params is not passed, unfortunately).  For now, I
just use a global variable to identify whether a prctl(2) should be
called before execve(2).

I'll try to think more about the way of passing this data (probably
vzctl already uses such global variables for implicit argument passing?).

Thanks,

-- 
Vasily

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ