Re: [PATCH] docs: clarify security-bugs disclosure policy
On Tue, Mar 6, 2018 at 3:31 PM, Dave Hansen wrote: > > 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. Ack. What we do is definitely not full disclosure. In fact, we often actively try to avoid disclosing details and leave that entirely to others. We disclose the *patches*, and the explanation of the patch, but not necessarily anything else (ie no exploit code or even any exploit discussion). We also don't explicitly disclose the discussion of the patches or the report, although part of it mayt obviously become more or less public for other reasons. So we should probably avoid using a term that means something else to a lot of people. And for similar reasons, I don't think the fixed verbiage should use "coordinated disclosure" either, like in your patch. That usually means the kind of embargoes that the security list does not honor. So I think it merits clarification, but maybe just specify the two things relevant to our disclosure: the fact that the patch and explanation for the patch gets made public (but not necessarily other effects), and that the timeframe is very limited. It's not full disclosure, it's not coordinated disclosure, and it's not "no disclosure". It's more like just "timely open fixes". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: clarify security-bugs disclosure policy
On Tue, Mar 6, 2018 at 3:31 PM, Dave Hansen wrote: > > From: Dave Hansen > > 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 secur...@kernel.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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] docs: clarify security-bugs disclosure policy
From: Dave Hansen 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. Signed-off-by: Dave Hansen Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Cc: Linus Torvalds Cc: Alan Cox Cc: Andrea Arcangeli Cc: Andy Lutomirski Cc: Kees Cook Cc: Tim Chen Cc: Dan Williams Cc: Alexander Viro Cc: Andrew Morton Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Mark Rutland --- b/Documentation/admin-guide/security-bugs.rst | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff -puN Documentation/admin-guide/security-bugs.rst~embargo Documentation/admin-guide/security-bugs.rst --- a/Documentation/admin-guide/security-bugs.rst~embargo 2018-03-06 14:47:04.519431230 -0800 +++ b/Documentation/admin-guide/security-bugs.rst 2018-03-06 14:57:46.410429629 -0800 @@ -29,18 +29,22 @@ made public. Disclosure -- -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. Coordination _ -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html