XFS security fix never sent to -stable?

XFS security fix never sent to -stable?

[Kees Cook]

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?

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security

Re: XFS security fix never sent to -stable?

[Dwight Engen]

On Thu, 5 Dec 2013 16:35:50 -0800
Kees Cook <keescook@google.com> 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?

I believe that would be appropriate, but would defer to Brian as the
original author of the eofblocks change.

> Thanks,
> 
> -Kees
> 

Re: XFS security fix never sent to -stable?

[Brian Foster]

On 12/06/2013 09:43 AM, Dwight Engen wrote:
> On Thu, 5 Dec 2013 16:35:50 -0800
> Kees Cook <keescook@google.com> 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?
> 
> I believe that would be appropriate, but would defer to Brian as the
> original author of the eofblocks change.
> 

I have no objection to proposing this for stable. The fix is
straightforward and isolated enough.

Brian

>> Thanks,
>>
>> -Kees
>>
> 

Re: XFS security fix never sent to -stable?

[Luis Henriques]

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?

Thanks Kees, I'm queuing it for the 3.11 kernel.

Cheers,
--
Luis

Re: XFS security fix never sent to -stable?

[Josh Boyer]

On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
<luis.henriques@canonical.com> wrote:
> 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?
>
> Thanks Kees, I'm queuing it for the 3.11 kernel.

There's also this one:

http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654

It fixes CVE-2013-6382

josh

Re: XFS security fix never sent to -stable?

[Dave Chinner]

[cc xfs list, cc stable@vger.kernel.org]

On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> <luis.henriques@canonical.com> wrote:
> > 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?
> >
> > Thanks Kees, I'm queuing it for the 3.11 kernel.
> 
> There's also this one:
> 
> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> 
> It fixes CVE-2013-6382

First I've heard about it there being a CVE for that bug. Since when
has it been considered best practice to publish CVEs without first
(or ever) directly contacting the relevant upstream developers?

But, regardless of how broken I think the CVE process is, commit
071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
picked up by the stable kernels.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS security fix never sent to -stable?

[Greg KH]

On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
> [cc xfs list, cc stable@vger.kernel.org]
> 
> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> > <luis.henriques@canonical.com> wrote:
> > > 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?
> > >
> > > Thanks Kees, I'm queuing it for the 3.11 kernel.
> > 
> > There's also this one:
> > 
> > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> > 
> > It fixes CVE-2013-6382
> 
> First I've heard about it there being a CVE for that bug. Since when
> has it been considered best practice to publish CVEs without first
> (or ever) directly contacting the relevant upstream developers?
> 
> But, regardless of how broken I think the CVE process is, commit
> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
> picked up by the stable kernels.

I don't see that commit in Linus's tree, is it not there yet?

thanks,

greg k-h

Re: XFS security fix never sent to -stable?

[Josh Boyer]

On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
>> [cc xfs list, cc stable@vger.kernel.org]
>>
>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
>> > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
>> > <luis.henriques@canonical.com> wrote:
>> > > 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?
>> > >
>> > > Thanks Kees, I'm queuing it for the 3.11 kernel.
>> >
>> > There's also this one:
>> >
>> > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
>> >
>> > It fixes CVE-2013-6382
>>
>> First I've heard about it there being a CVE for that bug. Since when
>> has it been considered best practice to publish CVEs without first
>> (or ever) directly contacting the relevant upstream developers?
>>
>> But, regardless of how broken I think the CVE process is, commit
>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
>> picked up by the stable kernels.
>
> I don't see that commit in Linus's tree, is it not there yet?

Not yet.  Ben said it's applied but I'm not sure where that is.

josh

Re: XFS security fix never sent to -stable?

[Eric Sandeen]

On 12/10/13, 7:15 AM, Josh Boyer wrote:
> On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
>>> [cc xfs list, cc stable@vger.kernel.org]
>>>
>>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
>>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
>>>> <luis.henriques@canonical.com> wrote:
>>>>> 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?
>>>>>
>>>>> Thanks Kees, I'm queuing it for the 3.11 kernel.
>>>>
>>>> There's also this one:
>>>>
>>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
>>>>
>>>> It fixes CVE-2013-6382
>>>
>>> First I've heard about it there being a CVE for that bug. Since when
>>> has it been considered best practice to publish CVEs without first
>>> (or ever) directly contacting the relevant upstream developers?
>>>
>>> But, regardless of how broken I think the CVE process is, commit
>>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
>>> picked up by the stable kernels.
>>
>> I don't see that commit in Linus's tree, is it not there yet?
> 
> Not yet.  Ben said it's applied but I'm not sure where that is.

xfs git tree:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06

-Eric

> josh

Re: XFS security fix never sent to -stable?

[Ben Myers]

Hi,

On Tue, Dec 10, 2013 at 08:31:23AM -0600, Eric Sandeen wrote:
> On 12/10/13, 7:15 AM, Josh Boyer wrote:
> > On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
> >>> [cc xfs list, cc stable@vger.kernel.org]
> >>>
> >>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> >>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> >>>> <luis.henriques@canonical.com> wrote:
> >>>>> 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?
> >>>>>
> >>>>> Thanks Kees, I'm queuing it for the 3.11 kernel.
> >>>>
> >>>> There's also this one:
> >>>>
> >>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> >>>>
> >>>> It fixes CVE-2013-6382
> >>>
> >>> First I've heard about it there being a CVE for that bug. Since when
> >>> has it been considered best practice to publish CVEs without first
> >>> (or ever) directly contacting the relevant upstream developers?
> >>>
> >>> But, regardless of how broken I think the CVE process is, commit
> >>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
> >>> picked up by the stable kernels.
> >>
> >> I don't see that commit in Linus's tree, is it not there yet?
> > 
> > Not yet.  Ben said it's applied but I'm not sure where that is.
> 
> xfs git tree:
> 
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06

I'll send a pull request containing this commit this afternoon.

Thanks,
	Ben

Re: XFS security fix never sent to -stable?

[Luis Henriques]

On Mon, Dec 09, 2013 at 11:56:21PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
> > [cc xfs list, cc stable@vger.kernel.org]
> > 
> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> > > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> > > <luis.henriques@canonical.com> wrote:
> > > > 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?
> > > >
> > > > Thanks Kees, I'm queuing it for the 3.11 kernel.
> > > 
> > > There's also this one:
> > > 
> > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> > > 
> > > It fixes CVE-2013-6382
> > 
> > First I've heard about it there being a CVE for that bug. Since when
> > has it been considered best practice to publish CVEs without first
> > (or ever) directly contacting the relevant upstream developers?
> > 
> > But, regardless of how broken I think the CVE process is, commit
> > 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
> > picked up by the stable kernels.
> 
> I don't see that commit in Linus's tree, is it not there yet?

This commit is now in Linus's:

31978b5 xfs: underflow bug in xfs_attrlist_by_handle()

Cheers,
--
Luis

Re: XFS security fix never sent to -stable?

[Josh Boyer]

On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> wrote:
> [cc xfs list, cc stable@vger.kernel.org]
>
> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
>> <luis.henriques@canonical.com> wrote:
>> > 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?
>> >
>> > Thanks Kees, I'm queuing it for the 3.11 kernel.
>>
>> There's also this one:
>>
>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
>>
>> It fixes CVE-2013-6382
>
> First I've heard about it there being a CVE for that bug. Since when
> has it been considered best practice to publish CVEs without first
> (or ever) directly contacting the relevant upstream developers?

We got a Fedora bug for it, and there are similar RHEL bugs open.  I
had assumed you would be informed either via upstream or through
those.  The CVE request was submitted by Kees here:
http://seclists.org/oss-sec/2013/q4/330

josh

Re: XFS security fix never sent to -stable?

[Dave Chinner]

On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote:
> On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com>
> wrote:
> > [cc xfs list, cc stable@vger.kernel.org]
> >
> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> >> <luis.henriques@canonical.com> wrote:
> >> > 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?
> >> >
> >> > Thanks Kees, I'm queuing it for the 3.11 kernel.
> >>
> >> There's also this one:
> >>
> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> >>
> >> It fixes CVE-2013-6382
> >
> > First I've heard about it there being a CVE for that bug. Since
> > when has it been considered best practice to publish CVEs
> > without first (or ever) directly contacting the relevant
> > upstream developers?
> 
> We got a Fedora bug for it, and there are similar RHEL bugs open.
> I had assumed you would be informed either via upstream or
> through those.

I've not been cc'd on any of those bugs internally at RH, so I don't
have visibility of the problems unless someone specifically adds me
to those bugs.  As it is, raising fedora/RHEL bugs is not informing
upstream - it is a distro process for tracking the distro issue
through to closure.

> The CVE request was submitted by Kees here:
> http://seclists.org/oss-sec/2013/q4/330

Ugh, no, I'm not going to subscribe to a high noise list where the
only way I might be informed of a CVE being raised is by following
links to git commit IDs....

Upstream is not magically informed about CVEs, and relying on
upstream developers to scan or poll *anything* just to find if a
CVE on their subsystem has been released is not reliable and
does not scale. If anyone raises a CVE against a kernel subsystem,
then the relevant list in the MAINTAINERS file for that subsystem
should be on the cc list of any discussion about the CVE, and on the
announcement of the CVE.

Security processes are not something that should be hidden away in
it's own private corner - if there's a problem upstream needs to
take action on, then direct contact with upstream is necessary. We
need to know about security issues - even ones that are classified
post-commit as security issues - so we are operating with full
knowledge of the issues in our code and the impact of our fixes....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS security fix never sent to -stable?

[Josh Boyer]

On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote:
>> On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com>
>> wrote:
>> > [cc xfs list, cc stable@vger.kernel.org]
>> >
>> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
>> >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
>> >> <luis.henriques@canonical.com> wrote:
>> >> > 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?
>> >> >
>> >> > Thanks Kees, I'm queuing it for the 3.11 kernel.
>> >>
>> >> There's also this one:
>> >>
>> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
>> >>
>> >> It fixes CVE-2013-6382
>> >
>> > First I've heard about it there being a CVE for that bug. Since
>> > when has it been considered best practice to publish CVEs
>> > without first (or ever) directly contacting the relevant
>> > upstream developers?
>>
>> We got a Fedora bug for it, and there are similar RHEL bugs open.
>> I had assumed you would be informed either via upstream or
>> through those.
>
> I've not been cc'd on any of those bugs internally at RH, so I don't
> have visibility of the problems unless someone specifically adds me
> to those bugs.  As it is, raising fedora/RHEL bugs is not informing
> upstream - it is a distro process for tracking the distro issue
> through to closure.

Agreed.  We should probably fix the bug thing anyway though.

>> The CVE request was submitted by Kees here:
>> http://seclists.org/oss-sec/2013/q4/330
>
> Ugh, no, I'm not going to subscribe to a high noise list where the
> only way I might be informed of a CVE being raised is by following
> links to git commit IDs....
>
> Upstream is not magically informed about CVEs, and relying on
> upstream developers to scan or poll *anything* just to find if a
> CVE on their subsystem has been released is not reliable and
> does not scale. If anyone raises a CVE against a kernel subsystem,
> then the relevant list in the MAINTAINERS file for that subsystem
> should be on the cc list of any discussion about the CVE, and on the
> announcement of the CVE.
>
> Security processes are not something that should be hidden away in
> it's own private corner - if there's a problem upstream needs to
> take action on, then direct contact with upstream is necessary. We
> need to know about security issues - even ones that are classified
> post-commit as security issues - so we are operating with full
> knowledge of the issues in our code and the impact of our fixes....

Agreed.  I'm going to interpret your comments at being directed to the
general audience because otherwise you're just shooting the messenger
:).

josh

Re: XFS security fix never sent to -stable?

[Dave Chinner]

On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote:
> > Security processes are not something that should be hidden away in
> > it's own private corner - if there's a problem upstream needs to
> > take action on, then direct contact with upstream is necessary. We
> > need to know about security issues - even ones that are classified
> > post-commit as security issues - so we are operating with full
> > knowledge of the issues in our code and the impact of our fixes....
> 
> Agreed.  I'm going to interpret your comments at being directed to the
> general audience because otherwise you're just shooting the messenger
> :).

Right, they are not aimed at you - they are aimed at those on the
security side of the fence. I'm tired of learning about CVEs in XFS
code through chinese whispers and/or luck.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS security fix never sent to -stable?

[Greg KH]

On Wed, Dec 11, 2013 at 01:00:07PM +1100, Dave Chinner wrote:
> On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
> > On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote:
> > > Security processes are not something that should be hidden away in
> > > it's own private corner - if there's a problem upstream needs to
> > > take action on, then direct contact with upstream is necessary. We
> > > need to know about security issues - even ones that are classified
> > > post-commit as security issues - so we are operating with full
> > > knowledge of the issues in our code and the impact of our fixes....
> > 
> > Agreed.  I'm going to interpret your comments at being directed to the
> > general audience because otherwise you're just shooting the messenger
> > :).
> 
> Right, they are not aimed at you - they are aimed at those on the
> security side of the fence. I'm tired of learning about CVEs in XFS
> code through chinese whispers and/or luck.

CVEs for the kernel are almost always "assigned" after the problem is
fixed, or when people "notice" something was changed upstream.  At that
point, there's no need for the original committer to be notified, as
there's nothing to do.

Anyway, I understand your frustration about CVEs, I don't like them much
either, but some people do, so let them deal with them, and don't give
them a second thought.

greg k-h

Re: XFS security fix never sent to -stable?

[Kees Cook]

On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
>> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote:
>> > Security processes are not something that should be hidden away in
>> > it's own private corner - if there's a problem upstream needs to
>> > take action on, then direct contact with upstream is necessary. We
>> > need to know about security issues - even ones that are classified
>> > post-commit as security issues - so we are operating with full
>> > knowledge of the issues in our code and the impact of our fixes....
>>
>> Agreed.  I'm going to interpret your comments at being directed to the
>> general audience because otherwise you're just shooting the messenger
>> :).
>
> Right, they are not aimed at you - they are aimed at those on the
> security side of the fence. I'm tired of learning about CVEs in XFS
> code through chinese whispers and/or luck.

Mostly I try to shield anyone not interested in CVEs from the boring
process, and try to focus on just getting things marked as needing to
go into stable. I don't think anyone needs to read the oss-security
list if they don't want to.

In this case, the fix Dan sent was part of a larger collection of
security issues reported by Nico. I think the communication error here
was Dan accidentally forgetting to add the Cc: stable tag. But beyond
that, it was sent to the xfs list and Cc: to security, so I'm not sure
it's fair to say it was hidden away. :)

Besides the missing Cc: stable tag, what should future patch senders
do to call attention to an issue being a security problem at the time
it is being reported?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: XFS security fix never sent to -stable?

[Dave Chinner]

On Tue, Dec 10, 2013 at 06:45:54PM -0800, Kees Cook wrote:
> On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote:
> >> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote:
> >> > Security processes are not something that should be hidden away in
> >> > it's own private corner - if there's a problem upstream needs to
> >> > take action on, then direct contact with upstream is necessary. We
> >> > need to know about security issues - even ones that are classified
> >> > post-commit as security issues - so we are operating with full
> >> > knowledge of the issues in our code and the impact of our fixes....
> >>
> >> Agreed.  I'm going to interpret your comments at being directed to the
> >> general audience because otherwise you're just shooting the messenger
> >> :).
> >
> > Right, they are not aimed at you - they are aimed at those on the
> > security side of the fence. I'm tired of learning about CVEs in XFS
> > code through chinese whispers and/or luck.
> 
> Mostly I try to shield anyone not interested in CVEs from the boring
> process, and try to focus on just getting things marked as needing to
> go into stable. I don't think anyone needs to read the oss-security
> list if they don't want to.

Which is how is should be. ;) All I want is some kind of
notification when a CVE raised for an XFS issue. It may be telling
us something we already known, but if:

	a) it has not yet been pushed upstream; or
	b) it was not marked for stable kernels at commit time; or
	c) don't have a fix for it yet

then it's an indication that we need to pay a little more attention
to this class of problem when we review similar fixes.

> In this case, the fix Dan sent was part of a larger collection of
> security issues reported by Nico. I think the communication error here
> was Dan accidentally forgetting to add the Cc: stable tag. But beyond
> that, it was sent to the xfs list and Cc: to security, so I'm not sure
> it's fair to say it was hidden away. :)

Right - this falls into the above category a) because of that. There
didn't appear to be any urgency because of the level of exposure of
the problem (i.e. need CAP_SYS_ADMIN to trip over it) and the fact
it's been like this for the past 10 years....

> Besides the missing Cc: stable tag, what should future patch senders
> do to call attention to an issue being a security problem at the time
> it is being reported?

Well, it may not be known at the time it's considered a security
issue, so I think that the best thing to do is make sure that when
a CVE is actually raise a note is sent to the relevant list just to
indicate 'CVE 1024-3267 has been raised for commit abcd1234
("xfs: knabgraddle the frobnozzle")'.

At least that way everyone - including XFS users - that there is an
issue that they might want to look out for and plan to upgrade their
stable kernels in the not-to-distant future...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS security fix never sent to -stable?

[Dan Carpenter]

I wasn't really expecting it to get a CVE since it requires
CAP_SYS_ADMIN but I should have added the CC to stable.  Sorry about
that.

regards,
dan carpenter

Re: XFS security fix never sent to -stable?

[Dave Chinner]

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

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: XFS security fix never sent to -stable?

[Kees Cook]

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