Date:	Mon, 1 Jun 2009 20:41:16 +0200
From:	Linus Turdvals <turdvals@...il.com>
To:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Cc:	rdunlap@...otime.net, security@...nel.org
Subject: [PATCH] Update security bugs policy in Documentation/SecurityBugs

This patch updates the security bugs handling policy in
Documentation/SecurityBugs, to match with the current practices
and philosophy of the Linux kernel security team.

Please apply to avoid the masturbating monkeys in the security
circus from reporting misleading bugs with no security impact
whatsoever.

Signed-off-by: Linus Turdvalds <turdvals@...il.com>

--- tricky/Documentation/SecurityBugs
+++ honest/Documentation/SecurityBugs
@@ -1,7 +1,20 @@
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible.  Please report security bugs to the
-Linux kernel security team.
+disclosed as quickly as possible.
+
+Unfortunately, since we do not believe in security bugs, your report
+could be classified as a reliability or performance problem. In such
+cases we will still fix the issue, but no specific disclosure will
+follow. Shall the reporter feel tempted to find references to said
+fix, he will require substantial amounts of time to walk through
+the commit logs in the affected git tree.
+
+Please report security bugs to the Linux kernel security team. We
+will provide the information to select members of the vendor-sec
+mailing list and Red Hat employees. The Linux kernel security team
+does not take any responsibility if said information is leaked or
+made available to third-parties through insecure communication
+channels.

 1) Contact

@@ -11,28 +24,46 @@ who will help verify the bug report and
 It is possible that the security team will bring in extra help from
 area maintainers to understand and fix the security vulnerability.

+The Linux kernel security team does not have a PGP public key at
+the moment, since information wants to be free.
+
 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
 REPORTING-BUGS if you are unclear about what information is helpful.
 Any exploit code is very helpful and will not be released without
 consent from the reporter unless it has already been made public.
+Please do not send us binary-only exploit code, because we have no
+idea about how to unpack it.

 2) 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
+to _not_ 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 solution is not well-tested, for vendor coordination or any other
+reason the team finds compelling, without any explanation required.
+However, we expect these delays to be short, measurable in days,
+not weeks or months. Please note that the vulnerability window might be
+measurable in years if the issue went unnoticed for such amounts of time.
 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
+holds the final say when setting a disclosure date. Once you report a
+security bug to the team, you lose all rights to the process and who
+will manage or have access to the information. The timeframe for
 disclosure is from immediate (esp. if it's already publically 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.
+disclosure date to be on the order of 30 days.

 3) Non-disclosure agreements

 The Linux kernel security team is not a formal body and therefore unable
 to enter any non-disclosure agreements.
+
+4) Enforcement of these terms
+
+The Linux kernel security team can absolutely ignore the terms herein,
+without explanations required. This document does not provide legally
+enforceable terms by any means, nor necessarily expresses the practices
+and philosophy of the current security team.
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists