lkml.org 
[lkml]   [2018]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.19 018/110] Documentation/security-bugs: Postpone fix publication in exceptional cases
    Date
    4.19-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Will Deacon <will.deacon@arm.com>

    commit 544b03da39e2d7b4961d3163976ed4bfb1fac509 upstream.

    At the request of the reporter, the Linux kernel security team offers to
    postpone the publishing of a fix for up to 5 business days from the date
    of a report.

    While it is generally undesirable to keep a fix private after it has
    been developed, this short window is intended to allow distributions to
    package the fix into their kernel builds and permits early inclusion of
    the security team in the case of a co-ordinated disclosure with other
    parties. Unfortunately, discussions with major Linux distributions and
    cloud providers has revealed that 5 business days is not sufficient to
    achieve either of these two goals.

    As an example, cloud providers need to roll out KVM security fixes to a
    global fleet of hosts with sufficient early ramp-up and monitoring. An
    end-to-end timeline of less than two weeks dramatically cuts into the
    amount of early validation and increases the chance of guest-visible
    regressions.

    The consequence of this timeline mismatch is that security issues are
    commonly fixed without the involvement of the Linux kernel security team
    and are instead analysed and addressed by an ad-hoc group of developers
    across companies contributing to Linux. In some cases, mainline (and
    therefore the official stable kernels) can be left to languish for
    extended periods of time. This undermines the Linux kernel security
    process and puts upstream developers in a difficult position should they
    find themselves involved with an undisclosed security problem that they
    are unable to report due to restrictions from their employer.

    To accommodate the needs of these users of the Linux kernel and
    encourage them to engage with the Linux security team when security
    issues are first uncovered, extend the maximum period for which fixes
    may be delayed to 7 calendar days, or 14 calendar days in exceptional
    cases, where the logistics of QA and large scale rollouts specifically
    need to be accommodated. This brings parity with the linux-distros@
    maximum embargo period of 14 calendar days.

    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Amit Shah <aams@amazon.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Co-developed-by: Thomas Gleixner <tglx@linutronix.de>
    Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    Documentation/admin-guide/security-bugs.rst | 19 ++++++++++---------
    1 file changed, 10 insertions(+), 9 deletions(-)

    --- a/Documentation/admin-guide/security-bugs.rst
    +++ b/Documentation/admin-guide/security-bugs.rst
    @@ -32,16 +32,17 @@ Disclosure and embargoed information
    The security list is not a disclosure channel. For that, see Coordination
    below.

    -Once a robust fix has been developed, our preference is to release the
    -fix in a timely fashion, treating it no differently than any of the other
    -thousands of changes and fixes the Linux kernel project releases every
    -month.
    +Once a robust fix has been developed, the release process starts. Fixes
    +for publicly known bugs are released immediately.

    -However, at the request of the reporter, we will postpone releasing the
    -fix for up to 5 business days after the date of the report or after the
    -embargo has lifted; whichever comes first. The only exception to that
    -rule is if the bug is publicly known, in which case the preference is to
    -release the fix as soon as it's available.
    +Although our preference is to release fixes for publicly undisclosed bugs
    +as soon as they become available, this may be postponed at the request of
    +the reporter or an affected party for up to 7 calendar days from the start
    +of the release process, with an exceptional extension to 14 calendar days
    +if it is agreed that the criticality of the bug requires more time. The
    +only valid reason for deferring the publication of a fix is to accommodate
    +the logistics of QA and large scale rollouts which require release
    +coordination.

    Whilst embargoed information may be shared with trusted individuals in
    order to develop a fix, such information will not be published alongside

    \
     
     \ /
      Last update: 2018-11-29 15:30    [W:4.407 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site