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.
--
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
