- Subject: Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
- From: Stephen Hemminger <shemminger@xxxxxxxxxx>
- Date: Fri, 12 Nov 2010 08:33:15 -0800
- Cc: Dan Rosenberg <drosenberg@xxxxxxxxxxxxx>, David Miller <davem@xxxxxxxxxxxxx>, socketcan@xxxxxxxxxxxx, kuznet@xxxxxxxxxxxxx, urs.thuermann@xxxxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx, kaber@xxxxxxxxx, jmorris@xxxxxxxxx, remi.denis-courmont@xxxxxxxxx, pekkas@xxxxxxxxxx, sri@xxxxxxxxxx, vladislav.yasevich@xxxxxx, tj@xxxxxxxxxx, lizf@xxxxxxxxxxxxxx, joe@xxxxxxxxxxx, hadi@xxxxxxxxxxxx, ebiederm@xxxxxxxxxxxx, adobriyan@xxxxxxxxx, jpirko@xxxxxxxxxx, johannes.berg@xxxxxxxxx, daniel.lezcano@xxxxxxx, xemul@xxxxxxxxxx, socketcan-core@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, linux-sctp@xxxxxxxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx
- In-reply-to: <1289546610.17691.1770.camel@edumazet-laptop>
- Organization: Vyatta
- References: <2129857903-1289528127-cardhu_decombobulator_blackberry.rim.net-1506931048-@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20101111.182939.258124014.davem@xxxxxxxxxxxxx> <1289529269.3090.207.camel@Dan> <1289546610.17691.1770.camel@edumazet-laptop>
On Fri, 12 Nov 2010 08:23:30 +0100
Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> Le jeudi 11 novembre 2010 à 21:34 -0500, Dan Rosenberg a écrit :
> > > I want whatever you replace it with to be equivalent for
> > > object tracking purposes.
> >
> > In nearly all of the cases I fixed, the socket inode is already
> > provided, which serves as a perfectly good unique identifier. Would you
> > prefer I include that information twice?
>
> Oh well. Please read this answer carefuly.
>
> Some facts to feed your next patch. I am very pleased you changed your
> mind and that we keep useful information in kernel log.
>
> 1) Inode numbers are not guaranteed to be unique. Its a 32bit seq
> number, and we dont check another socket inode use the same inode number
> (after 2^32 allocations it can happens)
>
> 2) /proc/net/ files can deliver same "line" of information several
> times, because of their implementation.
>
> 3) Because of SLAB_DESTROY_BY_RCU, same 'kernel socket pointer' can be
> seen several times in /proc/net/tcp & /proc/net/udp, but really on
> different "sockets"
>
> 4) Some good applications use both the socket pointer and inode number
> (tuple) to filter out the [2] problem. Dont break them, please ?
> Anything that might break an application must be at the very least
> tunable.
>
> In my opinion, a good thing would be :
>
> - Use a special printf() format , aka "secure pointer", as Thomas
> suggested.
>
> - Make sure you print different opaque values for two different kernel
> pointers. This is mandatory.
>
> - Make sure the NULL pointer stay as a NULL pointer to not let the
> hostile user know your secret, and to ease debugging stuff.
>
> - Have security experts advice to chose a nice crypto function, maybe
> jenkin hash. Not too slow would be nice.
>
>
> static unsigned long securize_kpointers_rnd;
>
> At boot time, stick a random value in this variable.
> (Maybe make sure the 5 low order bits are 0)
>
> unsigned long opacify_kptr(unsigned long ptr)
> {
> if (ptr == 0)
> return ptr;
> if (capable(CAP_NET_ADMIN))
> return ptr;
>
> return some_crypto_hash(ptr, &securize_kpointers_rnd);
> }
>
> At least, use a central point, so that we can easily add/change the
> logic if needed.
>
> Please provide this patch in kernel/printk.c for initial review, then
> once everybody is OK, you can send one patch for net tree.
>
> No need to send 10 patches if we dont agree on the general principle.
Also, the whole idea needs to be under a config option, so only
the paranoid idiots turn it on.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux OMAP]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]