lkml.org 
[lkml]   [2016]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/6] statx: Add a system call to make enhanced file info available
    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.

    Most file handles provided by filesystems are simply an encoding of
    the inode number + generation number, plus maybe the ino+gen of the
    parent dir if the NFS server is configured to do this. This makes it
    trivial for an attacker to guess what the likely generation numbers
    are going to be for inode numbers surrounding any given inode, hence
    greatly reducing the search space for guessing valid file handles.

    We've known this to be a problem for a long time - file handles are
    not cryptographically secure, so exposing information like this by
    default make guessing handles successfully almost trivial for many
    filesystems.

    In the latest XFS filesystem format, we randomise the generation
    value during every inode allocation to make it hard to guess the
    handle of adjacent inodes from an existing ino+gen pair, or even
    from life time to life time of the same inode. We don't use a secure
    random number generator (prandom_u32()) so it's still possible to
    guess with enough trial and observation. However, it makes it
    several orders of magnitude harder to guess and requires knowledge
    of inode allocation order to guess correctly once the random number
    sequence has been deduced and so makes brute force the only real
    option for guessing a valid handle for an inode.

    However, this is definitely a problem for the older format where
    each cluster of inodes was initialised with the same seed at cluster
    allocation time and the generation number was simply incremented for
    each life time. Most filesystems use a similar method for seeding
    and incrementing generation numbers, so once the generation numbers
    are exposed it makes handles trivial to calculate successfully.

    > 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....

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com

    \
     
     \ /
      Last update: 2016-05-05 01:21    [W:3.333 / U:0.288 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site