On Fri, Nov 12, 2010 at 08:32:01AM -0500, Dan Rosenberg wrote: > Hi Crypto people, > > I'm planning on submitting a patch that introduces a new %p format > specifier that obfuscates kernel pointers depending on privileges. This > change is for security reasons - many networking protocols expose > pointers to socket structures in their /proc interfaces, which are > attractive targets when exploiting other issues. > > It's been suggested that I initialize a secret value at boot, and use > that as the key to a crypto hash function. I should use a function that > is relatively fast (ideally), produces a unique output based on its > input of a pointer, and produces consistent output when given the same > input. It should be difficult to infer the input given only the output. > > I have two questions: > > 1. What is a proper, safe way of initializing a random value at boot? > Are there any existing examples that do this? > Just use get_random_bytes, or initalize an instance of cprng with get_random_bytes. > 2. Can you recommend a crypto algorithm that would be well suited for > this pointer obfuscation? > Depends on your goal, if you just wnat to hide the pointers, why not just print NULL instead of the value? If you want to maintain some level of uniqueness, just pull sizeof (void *) random bytes from whatever method above and add it to the pointer in question, and hope for the best. Honestly, though, I'm having trouble seeing the value of this. What interface in proc are you seeing that exposes pointers from kernel space in any meaningful way? and if those cases exist, isn't selinux the solution to preventing exposure of these values to processes without sufficient privlidges? Neil > Thanks, > Dan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
