Xen users - Jan 2013 - Security support for debug=y builds (Was Re: Xen Security Advisory 37 (CVE-2013-0154) - Hypervisor crash due to incorrect ASSERT (debug build only))

On Fri, 2013-01-04 at 16:01 +0000, Xen.org security team
wrote:
>      Hypervisor crash due to incorrect ASSERT (debug build only) 
While dealing with this issue the security team was faced with the
question as to whether bugs which are exposed only in debug=y builds
should be considered security relevant (i.e. would normally require an
embargo period, a full advisory, etc).

The Security Response Policy[0] does not offer any guidance on this
issue. We concluded that we should treat this issue as a normal Security
issue and then seek guidance from the community as to what we should do
in the future.

So what are your expectations for security sensitive bugs which only
affect debug builds? Note that debugging is disabled by default and that
we would recommended running non-debug builds in production.

Options which I can think of are:

      * debug=y bugs are Just Bugs and not security issues. i.e. they
        are discussed and fixed publicly on xen-devel and the fix is
        checked in in the usual way. There is no embargo or specific
        announcement. changelog may or may not refer to the security
        implications if debug=y is enabled.
      * debug=y bugs are security issues regardless, they are treated
        like any other security issue, i.e. following the process[0].
      * debug=y bugs are somewhere in the middle. (perhaps no embargo,
        less formal announcement etc etc)
      * ...

Any input appreciated. I will draft a process update as necessary based
on the response.

Ian.

[0] http://www.xen.org/projects/security_vulnerability_process.html

On 07/01/2013 10:21, "Ian Campbell" <ijc@xen.org> wrote:
> On Fri, 2013-01-04 at 16:01 +0000, Xen.org security team wrote:
>>      Hypervisor crash due to incorrect ASSERT (debug build only)
> 
> While dealing with this issue the security team was faced with the
> question as to whether bugs which are exposed only in debug=y builds
> should be considered security relevant (i.e. would normally require an
> embargo period, a full advisory, etc).
> 
> The Security Response Policy[0] does not offer any guidance on this
> issue. We concluded that we should treat this issue as a normal Security
> issue and then seek guidance from the community as to what we should do
> in the future.
> 
> So what are your expectations for security sensitive bugs which only
> affect debug builds? Note that debugging is disabled by default and that
> we would recommended running non-debug builds in production.
> 
> Options which I can think of are:
> 
>       * debug=y bugs are Just Bugs and not security issues. i.e. they
>         are discussed and fixed publicly on xen-devel and the fix is
>         checked in in the usual way. There is no embargo or specific
>         announcement. changelog may or may not refer to the security
>         implications if debug=y is enabled.
This is my preference. I consider debug builds to be developer builds, and
wouldn''t expect to see them used in production environments. We set
debug=n
by default in our stable branches for that reason.

 -- Keir
>       * debug=y bugs are security issues regardless, they are treated
>         like any other security issue, i.e. following the process[0].
>       * debug=y bugs are somewhere in the middle. (perhaps no embargo,
>         less formal announcement etc etc)
>       * ...
> 
> Any input appreciated. I will draft a process update as necessary based
> on the response.
> 
> Ian.
> 
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On 07/01/2013 10:21, "Ian Campbell" <ijc@xen.org> wrote:
> On Fri, 2013-01-04 at 16:01 +0000, Xen.org security team wrote:
>>      Hypervisor crash due to incorrect ASSERT (debug build only)
> 
> While dealing with this issue the security team was faced with the
> question as to whether bugs which are exposed only in debug=y builds
> should be considered security relevant (i.e. would normally require an
> embargo period, a full advisory, etc).
> 
> The Security Response Policy[0] does not offer any guidance on this
> issue. We concluded that we should treat this issue as a normal Security
> issue and then seek guidance from the community as to what we should do
> in the future.
> 
> So what are your expectations for security sensitive bugs which only
> affect debug builds? Note that debugging is disabled by default and that
> we would recommended running non-debug builds in production.
> 
> Options which I can think of are:
> 
>       * debug=y bugs are Just Bugs and not security issues. i.e. they
>         are discussed and fixed publicly on xen-devel and the fix is
>         checked in in the usual way. There is no embargo or specific
>         announcement. changelog may or may not refer to the security
>         implications if debug=y is enabled.
This is my preference. I consider debug builds to be developer builds, and
wouldn''t expect to see them used in production environments. We set
debug=n
by default in our stable branches for that reason.

 -- Keir
>       * debug=y bugs are security issues regardless, they are treated
>         like any other security issue, i.e. following the process[0].
>       * debug=y bugs are somewhere in the middle. (perhaps no embargo,
>         less formal announcement etc etc)
>       * ...
> 
> Any input appreciated. I will draft a process update as necessary based
> on the response.
> 
> Ian.
> 
> [0] http://www.xen.org/projects/security_vulnerability_process.html
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

>>> On 07.01.13 at 11:21, Ian Campbell <ijc@xen.org> wrote:
> Options which I can think of are:
> 
>       * debug=y bugs are Just Bugs and not security issues. i.e. they
>         are discussed and fixed publicly on xen-devel and the fix is
>         checked in in the usual way. There is no embargo or specific
>         announcement. changelog may or may not refer to the security
>         implications if debug=y is enabled.
+1
>       * debug=y bugs are security issues regardless, they are treated
>         like any other security issue, i.e. following the process[0].
-1
>       * debug=y bugs are somewhere in the middle. (perhaps no embargo,
>         less formal announcement etc etc)
+/-0

Jan

On 07/01/13 11:08, Keir Fraser wrote:
> On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
>
>> On Fri, 2013-01-04 at 16:01 +0000, Xen.org security team wrote:
>>>       Hypervisor crash due to incorrect ASSERT (debug build only)
>> While dealing with this issue the security team was faced with the
>> question as to whether bugs which are exposed only in debug=y builds
>> should be considered security relevant (i.e. would normally require an
>> embargo period, a full advisory, etc).
>>
>> The Security Response Policy[0] does not offer any guidance on this
>> issue. We concluded that we should treat this issue as a normal
Security
>> issue and then seek guidance from the community as to what we should do
>> in the future.
>>
>> So what are your expectations for security sensitive bugs which only
>> affect debug builds? Note that debugging is disabled by default and
that
>> we would recommended running non-debug builds in production.
>>
>> Options which I can think of are:
>>
>>        * debug=y bugs are Just Bugs and not security issues. i.e. they
>>          are discussed and fixed publicly on xen-devel and the fix is
>>          checked in in the usual way. There is no embargo or specific
>>          announcement. changelog may or may not refer to the security
>>          implications if debug=y is enabled.
> This is my preference. I consider debug builds to be developer builds, and
> wouldn''t expect to see them used in production environments. We
set debug=n
> by default in our stable branches for that reason.
>
>   -- Keir
I second this opinion.  Production environments should not be running 
development builds.

~Andrew
>
>>        * debug=y bugs are security issues regardless, they are treated
>>          like any other security issue, i.e. following the process[0].
>>        * debug=y bugs are somewhere in the middle. (perhaps no embargo,
>>          less formal announcement etc etc)
>>        * ...
>>
>> Any input appreciated. I will draft a process update as necessary based
>> on the response.
>>
>> Ian.
>>
>> [0] http://www.xen.org/projects/security_vulnerability_process.html
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On 07/01/13 11:08, Keir Fraser wrote:
> On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org>  wrote:
>
>> On Fri, 2013-01-04 at 16:01 +0000, Xen.org security team wrote:
>>>       Hypervisor crash due to incorrect ASSERT (debug build only)
>> While dealing with this issue the security team was faced with the
>> question as to whether bugs which are exposed only in debug=y builds
>> should be considered security relevant (i.e. would normally require an
>> embargo period, a full advisory, etc).
>>
>> The Security Response Policy[0] does not offer any guidance on this
>> issue. We concluded that we should treat this issue as a normal
Security
>> issue and then seek guidance from the community as to what we should do
>> in the future.
>>
>> So what are your expectations for security sensitive bugs which only
>> affect debug builds? Note that debugging is disabled by default and
that
>> we would recommended running non-debug builds in production.
>>
>> Options which I can think of are:
>>
>>        * debug=y bugs are Just Bugs and not security issues. i.e. they
>>          are discussed and fixed publicly on xen-devel and the fix is
>>          checked in in the usual way. There is no embargo or specific
>>          announcement. changelog may or may not refer to the security
>>          implications if debug=y is enabled.
> This is my preference. I consider debug builds to be developer builds, and
> wouldn''t expect to see them used in production environments. We
set debug=n
> by default in our stable branches for that reason.
>
>   -- Keir
I second this opinion.  Production environments should not be running 
development builds.

~Andrew
>
>>        * debug=y bugs are security issues regardless, they are treated
>>          like any other security issue, i.e. following the process[0].
>>        * debug=y bugs are somewhere in the middle. (perhaps no embargo,
>>          less formal announcement etc etc)
>>        * ...
>>
>> Any input appreciated. I will draft a process update as necessary based
>> on the response.
>>
>> Ian.
>>
>> [0] http://www.xen.org/projects/security_vulnerability_process.html
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> On 07/01/13 11:08, Keir Fraser wrote:
> > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> >>        * debug=y bugs are Just Bugs and not security issues. i.e.
they
> >>          are discussed and fixed publicly on xen-devel and the fix
is
> >>          checked in in the usual way. There is no embargo or
specific
> >>          announcement. changelog may or may not refer to the
security
> >>          implications if debug=y is enabled.
> > This is my preference. I consider debug builds to be developer builds,
and
> > wouldn''t expect to see them used in production environments.
We set debug=n
> > by default in our stable branches for that reason.
> >
> >   -- Keir
> 
> I second this opinion.  Production environments should not be running 
> development builds.
I tried to keep my initial mail unbiased, but this is my opinion too.

Ian.

On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> On 07/01/13 11:08, Keir Fraser wrote:
> > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> >>        * debug=y bugs are Just Bugs and not security issues. i.e.
they
> >>          are discussed and fixed publicly on xen-devel and the fix
is
> >>          checked in in the usual way. There is no embargo or
specific
> >>          announcement. changelog may or may not refer to the
security
> >>          implications if debug=y is enabled.
> > This is my preference. I consider debug builds to be developer builds,
and
> > wouldn''t expect to see them used in production environments.
We set debug=n
> > by default in our stable branches for that reason.
> >
> >   -- Keir
> 
> I second this opinion.  Production environments should not be running 
> development builds.
I tried to keep my initial mail unbiased, but this is my opinion too.

Ian.

On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> On 07/01/13 11:08, Keir Fraser wrote:
> > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> >>        * debug=y bugs are Just Bugs and not security issues. i.e.
they
> >>          are discussed and fixed publicly on xen-devel and the fix
is
> >>          checked in in the usual way. There is no embargo or
specific
> >>          announcement. changelog may or may not refer to the
security
> >>          implications if debug=y is enabled.
> > This is my preference. I consider debug builds to be developer builds,
and
> > wouldn''t expect to see them used in production environments.
We set debug=n
> > by default in our stable branches for that reason.
> >
> >   -- Keir
>
> I second this opinion.  Production environments should not be running
> development builds.
+1 but I''d still like to see such issues backported to stable branches.

Cheers,
James

On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> On 07/01/13 11:08, Keir Fraser wrote:
> > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> >>        * debug=y bugs are Just Bugs and not security issues. i.e.
they
> >>          are discussed and fixed publicly on xen-devel and the fix
is
> >>          checked in in the usual way. There is no embargo or
specific
> >>          announcement. changelog may or may not refer to the
security
> >>          implications if debug=y is enabled.
> > This is my preference. I consider debug builds to be developer builds,
and
> > wouldn''t expect to see them used in production environments.
We set debug=n
> > by default in our stable branches for that reason.
> >
> >   -- Keir
>
> I second this opinion.  Production environments should not be running
> development builds.
+1 but I''d still like to see such issues backported to stable branches.

Cheers,
James

On 07/01/2013 12:58, "James Bulpin" <James.Bulpin@eu.citrix.com>
wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
>> On 07/01/13 11:08, Keir Fraser wrote:
>>> On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
>>>>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
>>>>          are discussed and fixed publicly on xen-devel and the
fix is
>>>>          checked in in the usual way. There is no embargo or
specific
>>>>          announcement. changelog may or may not refer to the
security
>>>>          implications if debug=y is enabled.
>>> This is my preference. I consider debug builds to be developer
builds, and
>>> wouldn''t expect to see them used in production
environments. We set debug=n
>>> by default in our stable branches for that reason.
>>> 
>>>   -- Keir
>> 
>> I second this opinion.  Production environments should not be running
>> development builds.
> 
> +1 but I''d still like to see such issues backported to stable
branches.
Yes, this already happens and will not change.

 -- Keir
> Cheers,
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On 07/01/2013 12:58, "James Bulpin" <James.Bulpin@eu.citrix.com>
wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
>> On 07/01/13 11:08, Keir Fraser wrote:
>>> On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
>>>>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
>>>>          are discussed and fixed publicly on xen-devel and the
fix is
>>>>          checked in in the usual way. There is no embargo or
specific
>>>>          announcement. changelog may or may not refer to the
security
>>>>          implications if debug=y is enabled.
>>> This is my preference. I consider debug builds to be developer
builds, and
>>> wouldn''t expect to see them used in production
environments. We set debug=n
>>> by default in our stable branches for that reason.
>>> 
>>>   -- Keir
>> 
>> I second this opinion.  Production environments should not be running
>> development builds.
> 
> +1 but I''d still like to see such issues backported to stable
branches.
Yes, this already happens and will not change.

 -- Keir
> Cheers,
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On Mon, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
> > >>          are discussed and fixed publicly on xen-devel and
the fix is
> > >>          checked in in the usual way. There is no embargo or
specific
> > >>          announcement. changelog may or may not refer to the
security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer
builds, and
> > > wouldn''t expect to see them used in production
environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.
Looks like we have a consensus on this then.

Lars, could you add some words to the doc?

e.g. under "Scope of this process".

This process primarily covers the Xen Hypervisor Project. Vulnerabilties
reported against other Xen.org projects will be handled on a best effort
basis by the relevant Project Lead together with the security team.

On Mon, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
> > >>          are discussed and fixed publicly on xen-devel and
the fix is
> > >>          checked in in the usual way. There is no embargo or
specific
> > >>          announcement. changelog may or may not refer to the
security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer
builds, and
> > > wouldn''t expect to see them used in production
environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.
Looks like we have a consensus on this then.

Lars, could you add some words to the doc?

e.g. under "Scope of this process".

This process primarily covers the Xen Hypervisor Project. Vulnerabilties
reported against other Xen.org projects will be handled on a best effort
basis by the relevant Project Lead together with the security team.

On Mon, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
> > >>          are discussed and fixed publicly on xen-devel and
the fix is
> > >>          checked in in the usual way. There is no embargo or
specific
> > >>          announcement. changelog may or may not refer to the
security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer
builds, and
> > > wouldn''t expect to see them used in production
environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.
Looks like we have a consensus on this then.

I''m in two minds about whether this needs to be made explicit in the
vulnerability process.

If it were then e.g. "Scope of this process" could become:

        This process primarily covers the Xen Hypervisor Project and
        covers production configurations only, that is builds without
        debugging features enabled, e.g. debug=y.
        
        Vulnerabilties reported against other Xen.org projects will be
        handled on a best effort basis by the relevant Project Lead
        together with the security team.
        
Ian.

On Mon, 2013-01-07 at 11:36 +0000, Ian Campbell wrote:
> On Mon, 2013-01-07 at 11:21 +0000, Andrew Cooper wrote:
> > On 07/01/13 11:08, Keir Fraser wrote:
> > > On 07/01/2013 10:21, "Ian Campbell"<ijc@xen.org> 
wrote:
> > >>        * debug=y bugs are Just Bugs and not security issues.
i.e. they
> > >>          are discussed and fixed publicly on xen-devel and
the fix is
> > >>          checked in in the usual way. There is no embargo or
specific
> > >>          announcement. changelog may or may not refer to the
security
> > >>          implications if debug=y is enabled.
> > > This is my preference. I consider debug builds to be developer
builds, and
> > > wouldn''t expect to see them used in production
environments. We set debug=n
> > > by default in our stable branches for that reason.
> > >
> > >   -- Keir
> > 
> > I second this opinion.  Production environments should not be running 
> > development builds.
> 
> I tried to keep my initial mail unbiased, but this is my opinion too.
Looks like we have a consensus on this then.

I''m in two minds about whether this needs to be made explicit in the
vulnerability process.

If it were then e.g. "Scope of this process" could become:

        This process primarily covers the Xen Hypervisor Project and
        covers production configurations only, that is builds without
        debugging features enabled, e.g. debug=y.
        
        Vulnerabilties reported against other Xen.org projects will be
        handled on a best effort basis by the relevant Project Lead
        together with the security team.
        
Ian.

Ignore this one, hit send too soon.

Ignore this one, hit send too soon.

>>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> If it were then e.g. "Scope of this process" could become:
> 
>         This process primarily covers the Xen Hypervisor Project and
>         covers production configurations only, that is builds without
>         debugging features enabled, e.g. debug=y.
To me, with the wording above, the "debug=y" example here is
ambiguous (in that I could read it to mean only "debug=y" is
covered by the process, even if I agree that this makes little
sense).

Jan
>         Vulnerabilties reported against other Xen.org projects will be
>         handled on a best effort basis by the relevant Project Lead
>         together with the security team.
>         
> Ian.

>>> On 08.02.13 at 12:29, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> If it were then e.g. "Scope of this process" could become:
> 
>         This process primarily covers the Xen Hypervisor Project and
>         covers production configurations only, that is builds without
>         debugging features enabled, e.g. debug=y.
To me, with the wording above, the "debug=y" example here is
ambiguous (in that I could read it to mean only "debug=y" is
covered by the process, even if I agree that this makes little
sense).

Jan
>         Vulnerabilties reported against other Xen.org projects will be
>         handled on a best effort basis by the relevant Project Lead
>         together with the security team.
>         
> Ian.

On Fri, 2013-02-08 at 11:40 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 12:29, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> > If it were then e.g. "Scope of this process" could become:
> > 
> >         This process primarily covers the Xen Hypervisor Project and
> >         covers production configurations only, that is builds without
> >         debugging features enabled, e.g. debug=y.
> 
> To me, with the wording above, the "debug=y" example here is
> ambiguous (in that I could read it to mean only "debug=y" is
> covered by the process, even if I agree that this makes little
> sense).
yes, you are right.

I was trying to avoid having to explicitly list all the options while
also avoiding suggesting that other debug options, like perfc=y or (in
the future) coverage=y, might be supported.

Perhaps
        .... Therefore configurations built with e.g. debug=y are not
        covered by this process.

Ian.

On Fri, 2013-02-08 at 11:40 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 12:29, Ian Campbell
<Ian.Campbell@citrix.com> wrote:
> > If it were then e.g. "Scope of this process" could become:
> > 
> >         This process primarily covers the Xen Hypervisor Project and
> >         covers production configurations only, that is builds without
> >         debugging features enabled, e.g. debug=y.
> 
> To me, with the wording above, the "debug=y" example here is
> ambiguous (in that I could read it to mean only "debug=y" is
> covered by the process, even if I agree that this makes little
> sense).
yes, you are right.

I was trying to avoid having to explicitly list all the options while
also avoiding suggesting that other debug options, like perfc=y or (in
the future) coverage=y, might be supported.

Perhaps
        .... Therefore configurations built with e.g. debug=y are not
        covered by this process.

Ian.