xfs
[Top] [All Lists]

Re: XFS security fix never sent to -stable?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS security fix never sent to -stable?
From: Kees Cook <keescook@xxxxxxxxxx>
Date: Tue, 10 Dec 2013 18:36:11 -0800
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YHSCgu8jcpHrxj5p7eulRD7F85TMKD5S6DIFJyX9niI=; b=UezB4MzrZzlX+DVUuCHd4FL6lYRH26mDUK1RuZsRvwbXTj1tDp3gUbPWFbj4aSj62S BBxq8nXkMp7nxECVMgOevnr4USCo7OOVnPl0wpxYCJfWs56ltvkt6rx/oUg3c2sAFj/+ I/I5SVmjfWItTYn7FDbbAqmKr8Odt6WCLhRU5titkHUhY4bJW5EwH1QeYRTV24YzPsqS S6jfiIGof7iBTpU/faQ0iLC1mAK8FxSI9FZ+NRVKuD1Q7UrVeWdklsGI7NEciEb/IJB6 /1kDqFrd2qWh+AbxVaXFhHX3T2y4jlYiNWjky6cxcj95rqXBRhS84Rzwzyd5YAkbgZ6j gyog==
In-reply-to: <20131209233002.GV31386@dastard>
References: <CAGXu5jLKkgYg5UWJc8xBGN5NgDh68Q3YRxO--zmDL86BWPH78A@xxxxxxxxxxxxxx> <20131209233002.GV31386@dastard>
On Mon, Dec 9, 2013 at 3:30 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> [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
>> XFS_IOC_FREE_EOFBLOCKS ioctl").
>>
>> 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....

Right, it wasn't clear from the commit, and it looked troublesome, but
it's function wasn't obvious, so that's why I asked.

-Kees

-- 
Kees Cook
Chrome OS Security

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