linux-kernel - Re: [PATCH] docs: clarify security-bugs disclosure policy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5j+LYqK7knp369PmWb00O2rRidyyS7q10NCgiobhCCbP4w@mail.gmail.com>
Date:   Tue, 6 Mar 2018 16:30:54 -0800
From:   Kees Cook <keescook@...gle.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-doc@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] docs: clarify security-bugs disclosure policy

On Tue, Mar 6, 2018 at 3:31 PM, Dave Hansen <dave.hansen@...ux.intel.com> wrote:
>
> From: Dave Hansen <dave.hansen@...ux.intel.com>
>
> I think we need to soften the language a bit.  It might scare folks
> off, especially the:
>
>          We prefer to fully disclose the bug as soon as possible.
>
> which is not really the case.  As Greg mentioned in private mail, we
> really do not prefer to disclose things until *after* a fix.  The
> whole "we have the final say" is also a bit harsh.
> [...]
>  ----------
>
> -The goal of the Linux kernel security team is to work with the
> -bug submitter to bug resolution as well as disclosure.  We prefer
> -to fully disclose the bug as soon as possible.  It is reasonable to
> -delay disclosure when the bug or the fix is not yet fully understood,
> -the solution is not well-tested or for vendor coordination.  However, we
> -expect these delays to be short, measurable in days, not weeks or months.
> +The goal of the Linux kernel security team is to work with the bug
> +submitter to bug resolution as well as disclosure.  We prefer to fully
> +disclose the bug as soon as possible after a fix is available.  It is
> +customary to delay disclosure when the bug or the fix is not yet fully
> +understood, the solution is not well-tested or for vendor coordination.
> +However, we expect these delays to typically be short, measurable in
> +days, not weeks or months.
> +
>  A disclosure date is negotiated by the security team working with the
> -bug submitter as well as vendors.  However, the kernel security team
> -holds the final say when setting a disclosure date.  The timeframe for
> -disclosure is from immediate (esp. if it's already publicly known)
> -to a few weeks.  As a basic default policy, we expect report date to
> -disclosure date to be on the order of 7 days.
> +bug submitter as well as affected vendors.  The security team prefers
> +coordinated disclosure and will consider pre-existing, reasonable
> +disclosure dates.
> +
> +The timeframe for disclosure ranges from immediate (esp. if it's
> +already publicly known) to a few weeks.  As a basic default policy, we
> +expect report date to disclosure date to be on the order of 7 days.

This seems reasonable. Though I have two thoughts related to "we have
final say" and why it was there:

Sometimes we get insane embargo requests, and Linus has wanted to go
public ASAP. The wording was chosen to let reporters know that it is
possible for issues that don't need to wait 7 days to not wait 7 days.
For example, letting security@...nel.org know about a flaw and then
tell us to sit on it for 2 months until some public presentation,
that's not going to happen.

Additionally, we frequently make all network bugs immediately public,
since the net subsystem tends to reject embargoes.

So, maybe we could be more explicit about these cases? Or explicitly
describe what "reasonable" means (it's only hinted at).

-Kees

-- 
Kees Cook
Pixel Security