Date:	Fri, 27 May 2011 20:17:24 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dan Rosenberg <drosenberg@...curity.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tony Luck <tony.luck@...il.com>,
	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, May 27, 2011 at 10:46 AM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > If i understood you correctly you suggest randomizing the image 
> > by shifting the symbols in it around. The boot loader would still 
> > load an 'image' where it always loads it - just that image itself 
> > is randomized internally somewhat, right?
> 
> You snipped the other part of my email you responded to:
> 
>   For chrissake - you're doing the same thing. The only question is
>   "when" (and the fact that if you do it at install-time, you can do a
>   fancier job of it)
> 
> ie the fact that if you do it at install-time, you have the option of
> being much more fancy about it.
> 
> So sure, the install time option *can* do more. It doesn't *have* 
> to do more.
> 
> But being able to do a better job of randomization is *better*. Ok? 
> It doesn't mean you have to, but you have more options to do things 
> if you want to.
> 
> IOW, there is absolutely zero difference between doing it at 
> install-time or run-time, but the install-time one is (a) likely 
> easier and (b) certainly more flexible. But both of them do the 
> exact same thing, and require the exact same support in things like 
> /proc/kallsyms.
> 
> Of course, if we end up doing something really fancy (which the 
> install-time option allows), that obviously does mean that the 
> remapping by %pK thing for kallsyms needs to be much smarter too.
> 
> But at %pK time, you can *afford* to do that kind of things. At 
> boot-time, before you're even loaded and have a hard time even 
> parsing the e820 maps? Yeah, you're not going to do anything smart 
> there, I can tell you.

Ok, you are right, we could patch in all the things into the image at 
install time to be able to 'derandomize' symbols and still be able to 
provide them.

[ One worry i have is that distro logic is to go for the simplest 
  route: which is to randomize the symbols by padding the beginning 
  or the end of the kernel image a bit, but don't bother making %pK 
  smart or fancy. This means that /proc/kallsyms will be restricted 
  (maybe even turned off completely, because it's now broken) and a 
  'real' System.map put, only readable to root. This still 'allows'
  tooling, in a full SystemTap and Oprofile usability fashion. ]

Anyway, this strikes off the second item from my list. Meanwhile i 
also found two other usecases which i added to the head of the list:

 - Boot time dynamic randomization allows randomization of 'mass 
   install' systems, where the same image is used, to still be 
   randomized: for example a million phones all with the same Flash 
   ROM image and no 'install' performed at all on them.

   With static randomization these systems will all have the same
   kernel addresses.

 - Boot time dynamic randomization allows read-only systems to still 
   be randomized: for example internet cafes that use some popular 
   pre-packaged kiosk-mode live-DVD. They probably wont bother 
   randomizing and relinking the ISOs per machine and burning per 
   machine DVDs ...

 - A root exploit will still not give away the location of the
   kernel (assuming module loading has been disabled after bootup),
   so a rootkit cannot be installed 'silently' on the system, into
   RAM only, evading most offline-storage-checking tools.

   With static linking this is not possible: reading the kernel image
   as root trivially exposes the kernel's location.

 - Crash & reboot & retry brute force exploits get harder: if one
   attempt at an exploit causes a crash and a reboot, the kernel
   addresses are different after the reboot so the attempt has to be
   retried without the advantage of any prior history.

   With static linking this kind of exploit is somewhat easier: every
   crash gives a permanent proof that the guessed RIP offet was
   wrong, so history can be used on subsequent retries.

 - It gives a way to go one step further in secure server lockdown:
   where even root with full access to all storage has no way to
   break into the kernel. Reboots, module loading and kexec can be
   controlled, ioperm() and iopl() can be restricted. If those are
   taken away then even if a root exploit allows the attacker to
   overwrite the kernel image, a reboot has to be waited for and if
   reboots do sanity checks [based on immutable storage] of the
   system then the exploit can be found.

   With static linking this is not possible: reading the kernel image
   as root trivially exposes the kernel's location.

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/

Powered by blists - more mailing lists