[ubuntu-hardened] KASLR: enabling on x86 with "kaslr" option via '/etc/default/grub' file.

[Kees Cook]

On Tue, Aug 01, 2017 at 03:44:38PM -0700, Seth Arnold wrote:
> On Sun, Jul 30, 2017 at 11:48:50AM +0200, daniel curtis wrote:
> > So, are You trying to say, that enabling "kaslr" does not improve system
> > security? After adding "kaslr" option to the '/etc/default/grub' file,
> > generate a grub2 config file via update-grub(8) command, two values
> > "commit_creds" and "prepare_kernel" (from '/proc/kallsysms' file) were
> > randomized each time, during system starts.
> > 
> > However, without "kaslr", both values are the same - after every system
> > start. Additionally, I've also used - recommended by Developers -
> > 'kptr_restrict' and 'dmesg_restrict'. So maybe it is not so bad on x86
> > architecture? These values can be checked with this command:
> > 
> > [~]# cat /proc/kallsyms | grep ' commit_creds\| prepare_kernel'
> > ffffffdc08e960  T commit_creds
> > ffffffdc08ed30  T prepare_kernel_cred
> > 
> > In this case, "kaslr" is in use. That's just an example. As I already
> > mentioned: without KASLR, both values have the same value. By the way;
> 
> So, the thing is, the two numbers here will change from boot to boot but
> they will almost certainly be the same distance apart every single boot
> regardless of their actual values. (Did I get it right? :)
> 
> I believe using kaslr is more secure than not using kaslr. But it's not magic.

One additional note here is that Linux kernel v4.8 and later (in Zesty
and later) has CONFIG_RANDOMIZE_MEMORY which shuffles where a number
of memory sections live in memory at each boot too. This makes several
common targets (e.g. the page tables) harder to predict for an attacker.
(This protection isn't easy to check on a default system; there isn't a
place to see where vmap, page tables, etc are located like there is for
the kernel with /proc/kallsyms.)

Additionally v4.12 and later (in Ubuntu after Artful) KASLR is enabled
by default.

-Kees

-- 
Kees Cook