[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1304051408540.23195@twin.jikos.cz>
Date: Fri, 5 Apr 2013 14:12:20 +0200 (CEST)
From: Jiri Kosina <jkosina@...e.cz>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org,
kernel-hardening@...ts.openwall.com,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
x86@...nel.org, Jarkko Sakkinen <jarkko.sakkinen@...el.com>,
Matthew Garrett <mjg@...hat.com>,
Matt Fleming <matt.fleming@...el.com>,
Eric Northup <digitaleric@...gle.com>,
Dan Rosenberg <drosenberg@...curity.com>,
Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 3/3] x86: kernel base offset ASLR
On Thu, 4 Apr 2013, Kees Cook wrote:
> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel
> can be randomized at boot.
>
> This makes kernel vulnerabilities harder to reliably exploit, especially
> from remote attacks and local processes in seccomp containers. Keeping
> the location of kernel addresses secret becomes very important when using
> this feature, so enabling kptr_restrict and dmesg_restrict is recommended.
If we are going to take the KASLR path at all, and assuming this is done
purely because of security, I'd suggest not only vaguely mentioning this
requirement in the changelog (and calling it recommendation), but make it
a hard prerequisity.
Without kernel addresses being invisible to userspace, this feature is
completely useless, but might provide very false sense of security if just
blindly enabled by random Joe Bofh.
--
Jiri Kosina
SUSE Labs
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.
