linux-kernel - Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 05 May 2016 10:09:49 +1000
From:	NeilBrown <nfbrown@...ell.com>
To:	Dave Chinner <david@...morbit.com>,
	David Howells <dhowells@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-afs@...r.kernel.org,
	linux-nfs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thu, May 05 2016, Dave Chinner wrote:

> On Fri, Apr 29, 2016 at 01:57:43PM +0100, David Howells wrote:
>>  (4) File creation time (st_btime*), data version (st_version), inode
>>      generation number (st_gen).
>> 
>>      These will be returned if available whether the caller asked for them or
>>      not.  The corresponding bits in st_mask will be set or cleared as
>>      appropriate to indicate a valid value.
>
> IMO, exposing the inode generation number to anyone is a potential
> security problem because they are used in file handles.

"security through obscurity".  We have Kerberos working really nicely
for NFS these days.  Do we still care?

What if the generation number were only made available to "root"?  Would
that allay your concerns?
Would that still be useful?
We already have name_to_handle_at().  Exposing the generation number
could/should follow the same rules at that.  Or maybe the exposure of
each field should be guided by the filesystem, depending on (for
example) whether it is used to provide uniqueness to the filehandle.

>
>>      If the caller didn't ask for them, then they may be approximated.  For
>>      example, NFS won't waste any time updating them from the server, unless
>>      as a byproduct of updating something requested.
>
> I would suggest that exposing them from the NFS server is something
> we most definitely don't want to do because they are the only thing
> that keeps remote users from guessing filehandles with ease....

Given that the NFS protocol does not define a "generation number"
attribute, I think there is no risk for them being exposed from the NFS
server ... except implicitly within the filehandle of course.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)