Messages in this thread | | | From | Kyle Moffett <> | Date | Fri, 18 Nov 2011 20:09:12 -0500 | Subject | Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects that can be shared between tasks |
| |
On Fri, Nov 18, 2011 at 18:46, Tejun Heo <tj@kernel.org> wrote: > Hello, > > On Fri, Nov 18, 2011 at 05:10:37PM -0500, Kyle Moffett wrote: >> The #1 rule of one-time pads is never use it for more than one thing, >> and you use it here for every object in the system. > > The new version is using different poison for different types of > objects.
Even still, if you use a one-time pad (IE: XOR with a random data value) to obscure more than exactly 1 object total, ever, all of its security properties are null and void.
>> If you actually want to be able to compare uniqueness without exposing >> anything vulnerable to various kinds of guessing, you should generate >> a random 64-bit value for each class of object and then use a proper >> cryptographic hash function on it: >> crypto_hash(concat(object_ptr, random_value)) >> >> Even given the best possible practical attacks against SHA1 or MD5 >> today both still provides more than enough security to prevent someone >> from guessing "object_ptr" in less than an absurd amount of time. > > So, per-type poison + crypto hash, it is then.
Yes. I haven't thought through whether or not you would ever care about a system giving out the same number for two different kinds of object. The only possible vulnerability I can think of would be if the kernel had a use-after-free bug... You could allocate and free a bunch of the vulnerable objects and use this data-structure-ID system to find an allocated data-structure of a different type which matches up with one of the used-after-freed ones. Then in theory you could compromise something, I suppose.
Sort of an off-the-wall scenario, I will admit.
The per-type random value is certainly a safe bet and should have zero actual impact on performance. Good luck!
Cheers, Kyle Moffett
-- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |