From: Solar Designer <solar@openwall.com>
To: kernel-hardening@lists.openwall.com
Cc: Will Drewry <wad@chromium.org>
Subject: Re: [kernel-hardening] 32/64 bitness restriction for pid namespace
Date: Wed, 10 Aug 2011 17:03:33 +0400 [thread overview]
Message-ID: <20110810130333.GA31122@openwall.com> (raw)
In-Reply-To: <20110810095200.GA2377@albatros>
On Wed, Aug 10, 2011 at 01:52:01PM +0400, Vasiliy Kulikov wrote:
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -151,6 +151,8 @@ ENTRY(ia32_sysenter_target)
> .quad 1b,ia32_badarg
> .previous
> GET_THREAD_INFO(%r10)
> + testl $_TIF_SYSCALL32_DENIED,TI_flags(%r10)
> + jnz ia32_deniedsys
Things like this work for the initial RFC posting, but something will
need to be done to eliminate the performance impact later.
Perhaps bitness-restricted processes will need to be switched to
directly use different syscall entry code. Maybe you'll have to do such
switching on context switches, which is hopefully a lower performance
impact than the check on syscall entry. On the other hand, this is more
complicated and may have extra risks.
Alternatively, you may do the test/jnz thing on some syscall mechanisms
(legacy), but do something more efficient on others (meant to be fast).
You'll need to research this and propose something. Or maybe folks on
LKML will propose something.
> +ia32_deniedsys:
> + /* FIXME: need SIGSEGV delivery or similar */
I think the action on error should be exactly the same as if the kernel
is compiled without CONFIG_IA32_EMULATION.
> +static struct ctl_table abi_syscall_restrict[] = {
> + {
> + .procname = "bitness_locked",
> + .mode = 0644,
> + .proc_handler = bitness_locked_handler
> + },
> + {}
> +};
How would we actually configure it, say, for an OpenVZ container before
we let any program in the container run (including /sbin/init, because
we assume that the container's root account may have been compromised
and is now trying to attack the kernel to escape)? With OpenVZ, this
setting will need to be in /etc/vz/conf/100.conf, etc. - and vzctl will
need to configure it in the kernel. Will it have to mount the
container's procfs early for this? Currently, this step is left for
the guest Linux distro's startup scripts.
Also, what are the possible settings? Is this tri-state - any bitness
allowed, 32-bit only, or 64-bit only?
Thanks,
Alexander
next prev parent reply other threads:[~2011-08-10 13:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-07 11:00 [kernel-hardening] 32/64 bitness restriction for pid namespace Vasiliy Kulikov
2011-08-08 17:39 ` [kernel-hardening] " Vasiliy Kulikov
2011-08-10 9:52 ` Vasiliy Kulikov
2011-08-10 13:03 ` Solar Designer [this message]
2011-08-10 13:27 ` [kernel-hardening] " Vasiliy Kulikov
2011-08-10 14:26 ` Solar Designer
2011-08-10 15:02 ` Vasiliy Kulikov
2011-08-10 15:40 ` Solar Designer
2011-08-10 16:21 ` Vasiliy Kulikov
2011-08-10 16:42 ` Solar Designer
2011-08-12 12:07 ` Vasiliy Kulikov
2011-08-12 12:23 ` Solar Designer
2011-08-13 15:12 ` Vasiliy Kulikov
2011-08-13 15:19 ` Solar Designer
2011-08-13 16:55 ` Vasiliy Kulikov
2011-08-13 17:31 ` Vasiliy Kulikov
2011-08-13 19:25 ` Solar Designer
2011-08-13 19:22 ` Solar Designer
2011-08-14 9:50 ` Solar Designer
2011-08-14 10:16 ` Vasiliy Kulikov
2011-08-14 11:29 ` Solar Designer
2011-08-14 11:55 ` Vasiliy Kulikov
2011-08-14 12:04 ` Solar Designer
2011-08-14 12:16 ` Vasiliy Kulikov
2011-08-15 15:38 ` Vasiliy Kulikov
2011-08-15 21:33 ` Solar Designer
2011-08-16 6:39 ` Vasiliy Kulikov
2011-08-15 21:46 ` Solar Designer
2011-08-16 6:25 ` Vasiliy Kulikov
2011-08-18 10:34 ` Solar Designer
2011-08-18 14:42 ` Vasiliy Kulikov
2011-08-12 9:09 ` Vasiliy Kulikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110810130333.GA31122@openwall.com \
--to=solar@openwall.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox