[Top] [All Lists]

Re: XFS security fix never sent to -stable?

To: Kees Cook <keescook@xxxxxxxxxx>
Subject: Re: XFS security fix never sent to -stable?
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 10 Dec 2013 10:30:02 +1100
Cc: Dwight Engen <dwight.engen@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Brian Foster <bfoster@xxxxxxxxxx>, Dave Chinner <dchinner@xxxxxxxxxx>, Gao feng <gaofeng@xxxxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAGXu5jLKkgYg5UWJc8xBGN5NgDh68Q3YRxO--zmDL86BWPH78A@xxxxxxxxxxxxxx>
References: <CAGXu5jLKkgYg5UWJc8xBGN5NgDh68Q3YRxO--zmDL86BWPH78A@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
[CC the xfs list. Kees - I shouldn't have to remind you to do this. ]

On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote:
> Hi,
> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add
> capability check to free eofblocks ioctl") is a security fix that was
> never sent to -stable? From what I can see, it was introduced in 3.8
> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add
> I don't see this in the 3.8.y tree. Should it be added there and newer?

Well, it's not really a security problem at all, given that it only
affects speculative preallocation beyond EOF. i.e. it affects
filesystem metadata that does not yet index any user data.

Indeed, the kernel already does exactly what this ioctl does every 5
minutes without user intervention. i.e. it's simply a maintenance
task we need to execute periodically or on demand as a result of
other events (e.g. from a userspace daemon that is listen to quota
exhaustion messages).

So apart from allowing a user to burn some CPU with the ioctl doing
nothing but scanning, there's little in way of a security problem
being exposed on kernels prior to 3.12 here.

The reason for the cap check? Turning off this ioctl in containers
restricted by user name spaces. i.e. new functionality added to XFS
in 3.12 introduced curiously vague and difficult to explain new
inode access restrictions, so we took the "be safe by default" route
and only allowed the init namespace access to the ioctl....


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>