linux-kernel - Re: [PATCH] pipefs unique inode numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Jan 2007 19:12:53 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Bodo Eggert <7eggert@....de>, akpm@...l.org, dev@...ru,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	torvalds@...l.org
Subject: Re: [PATCH] pipefs unique inode numbers

Linus Torvalds wrote:
> 
> On Tue, 30 Jan 2007, Bodo Eggert wrote:
>> change pipefs to use a unique inode number equal to the memory
>> address unless it would be truncated.
> 
> I *really* wouldn't want to expose kernel addresses to user space, it just 
> ends up being a piece of data that they shouldn't have. If we have some 
> security issue, this is just too much kernel information that a bad user 
> could get at.
> 
> 		Linus

Agreed. That was my reasoning for proposing the earlier patch that xor'ed
it with a random value (though that's pretty thin protection too).

I think in hindsight though, just pulling the patch that hashes pipefs
inodes is probably the best thing for now. At some point in the future,
if we decide it's enough of a problem, we can always revisit it.

I'm still planning to look over other callers of new_inode to make a
determination about them wrt to i_ino uniqueness. Many of them are not
as performance sensitive as pipefs, and it might not be such a big deal
to just hash those.

-- Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/