linux-kernel - Re: XFS security fix never sent to -stable?

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]

Message-ID: <CAGXu5j+u0xSN7jQk8udLefMAa5xNSNHU98as33QYHWOyv-JuJw@mail.gmail.com>
Date:	Tue, 10 Dec 2013 18:36:11 -0800
From:	Kees Cook <keescook@...gle.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	Dwight Engen <dwight.engen@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Brian Foster <bfoster@...hat.com>,
	Dave Chinner <dchinner@...hat.com>,
	Gao feng <gaofeng@...fujitsu.com>, Ben Myers <bpm@....com>,
	Greg KH <gregkh@...uxfoundation.org>, xfs@....sgi.com
Subject: Re: XFS security fix never sent to -stable?

On Mon, Dec 9, 2013 at 3:30 PM, Dave Chinner <david@...morbit.com> 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
--
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/