linux-kernel - Re: [RFC][PATCH] Randomize kernel base address on boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110527134617.GD23626@elte.hu>
Date:	Fri, 27 May 2011 15:46:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Tony Luck <tony.luck@...il.com>,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	torvalds@...ux-foundation.org, adobriyan@...il.com,
	penberg@...nel.org, hpa@...or.com,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Valdis.Kletnieks@...edu, pageexec@...email.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot

* Dan Rosenberg <drosenberg@...curity.com> wrote:

> > And if this randomization is also to protect information from 
> > root user then /proc/iomem exporting the physical address of 
> > kernel is still a valid question in that context.
> 
> I think we can deal with unprivileged users first, and if we want 
> to truly prevent root from finding this out, we can introduce a 
> separate toggle that locks things down further.

Correct, the case of unprivileged users should be handled first and 
it should be handled separately from any root-restrictions.

I only raised this to have a rough record of what would have to 
happen there.

Once all is said, done, committed and tested (the last two not 
necessarily in that order), we can look at any open root-restrict 
questions. It's a lot less clear-cut from a system usability POV.

If we do it we probably want one central one-shot 'restrict root from 
now on' toggle, not the separate switches that kill kexec and module 
loading separately.

Some shops might even want to disable root from being able to reboot 
the system and restrict reboots to physically performed (and 
crash/panic/hang induced) reboots only.

Some shops might want to make reboots dependent on the provision of a 
secret key. That key would not be stored on that system.

So there's lots of details to sort out in the "keep root from being 
able to break into the kernel and hide a rootkit out and disappear" 
area.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/