* Eric Dumazet [off-list ref] wrote:

Le jeudi 26 mai 2011 à 22:44 -0400, David Miller a écrit :

quoted

From: Kees Cook <redacted>
Date: Thu, 26 May 2011 17:14:49 -0700

quoted

We got this dropped from the /proc view; why can't we do the same for
this netlink interface?

Because it's not only an opaque "output" blob, it's also an input key
for lookups which the user can trigger.

Yes, we wan add a layer to obfuscate the real pointers. We dont 
trust values given by user, only match them.

Either we use a XOR with a boot time random value (but let the NULL 
cookie being the NULL one), or we generate an unique 64bit socket 
id for the cookie (and keep a 64bit cookie in all sockets, 
increasing ram usage)

FYI, Dan Rosenberg is currently working on a kernel image 
randomization feature, see this lkml thread:

   [RFC][PATCH] Randomize kernel base address on boot

That will come with an easy vsprintf method to 'unrandomize' IPs. 

( this will be used to display a real-looking /proc/kallsyms and all 
  IPs that the kernel passes to user-space (via perf, etc.) will be 
  unrandomized as well, protecting the randomization seed. )

Once that code goes upstream the networking code could rather simply 
use it to 'randomize' these real data pointers as well. (Assuming you 
never ever pass in zero, that would expose the secret seed.)

The only worry would be statistical analysis performed by local 
attackers: by creating and closing enough sockets on a busy system 
you can over time cover almost all ranges of RAM, so if you can 
observe a pattern of 'over the address space limit' addresses at the 
top or the bottom of the address space you can estimate the random 
seed to within 4-5 bits realistically, maybe even more.

The upper and lower limit of the address space (big holes are useful 
too) can be calculated rather precisely based on RAM size, the 
identity of the system and the kernel version.

So maybe networking real-pointer randomization should be separate 
from kernel IP randomization after all.

Thanks,

	Ingo