On Fri, Nov 17, 2006 at 08:43:00AM -0500, Jeff Layton wrote: > 2) this scheme would effectively leak inode addresses into userspace. > I'm not sure if that would be exploitable, but it's probably best not to > do it. The patch adds a static unsigned int that is initialized to a > random value at boot time. We'll xor the inode offset with this value. > That should allow for a unique i_ino value, but since the xor mask would > be secret, it shouldn't be possible to turn it back into an address. > There may be a more secure way to do this. I'm definitely open to > suggestions here. I *think* the xor mask is mere obfuscation. It looks likely that you can recover it with a little bit of trial and error. If you can force the filesystem to hand you back new inodes quickly such that there is a high probability you get consecutive allocations, you'll get a sequence which would be spaced 700-odd bytes apart, except that it's been xored. Since you know it's incrementing, if you see the sequence decrease, you'll know that was a 1 in that bit. It'd be a bit more complex than that, and cryptanalysis was never my forte, but I suspect we should either use a folded hash like md5, or give up and just divide the address by sizeof(struct inode). Sure, divides are slow, but this is a divide by a constant, so it shouldn't be that bad. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
