To keep the conversation concrete, here's a pretty rough stab at
documenting the policy.
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.
1) Contact
The Linux kernel security contact is $CONTACTADDR. This is a private
list of security officers who will help verify the bug report and develop
and release a fix. It is possible that the security officers will bring
in extra help from area maintainers to understand and fix the security
vulnerability.
It is preferred that mail sent to the security contact is encrypted
with $PUBKEY.
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's already been made public.
2) Disclosure
The goal of the kernel security contact 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. As a basic default
policy, we expect report to disclosure to be on the order of $NUMDAYS.
On Iau, 2005-01-13 at 20:55, Chris Wright wrote:
> To keep the conversation concrete, here's a pretty rough stab at
> documenting the policy.
It's not documenting the stuff Linus seems to be talking about which is
a public list ? Or does Linus want both ?
> It is preferred that mail sent to the security contact is encrypted
> with $PUBKEY.
https:// and bugs.kernel.org ? You can make bugzilla autoprivate
security bugs and alert people.
> well-tested or for vendor coordination. However, we expect these delays
> to be short, measurable in days, not weeks or months. As a basic default
> policy, we expect report to disclosure to be on the order of $NUMDAYS.
Sounds good. $NUMDAYS is going to require some debate. My gut feeling is
14 days is probably the right kind of target for hard stuff remembering
how long it takes to run QA on an enterprise grade kernel. If it gets
too short then vendors are going to disclose elsewhere for their own
findings and only to this list when they are all ready anyway which
takes us back to square one.
And many are probably a lot less - those nobody is going to rush out and
build new vendor kernels for, or those that prove to be non serious can
probably get bumped to the public list by the security officer within a
day or two.
Alan
On Thu, 13 Jan 2005, Alan Cox wrote:
>
> It's not documenting the stuff Linus seems to be talking about which is
> a public list ? Or does Linus want both ?
I see myself as pretty extreme when it comes to my approach to security.
And I actually distrust extremes. I'm at one end of the spectrum, and
vendor-sec is at the other (I'm not even counting the head-in-the-sand
approach as part of the spectrum ;). Knowing that, I'd expect that most
people are somewhere in between.
Which to me implies that while what I personally _want_ is total openness,
that's not necessarily what makes the most sense in real life.
So I want to give people choice. I want to encourage openness. But hell,
if we have a closed list with a declared short embargo that is known to
not play games (ie clock starts ticking from original discovery, not from
somebody elses embargo), that's good too.
Let people vote with their feet. If vendor-sec ends up being where all the
"important" things are discussed - so be it. We've not lost anything, and
at worst a "kernel-security" list would be a way to discuss stuff that was
already released by vendor-sec.
Linus
* Chris Wright:
> To keep the conversation concrete, here's a pretty rough stab at
> documenting the policy.
Looks fine. Maybe you can add the following section?
3) Non-disclosure agreements
The Linux kernel security contact is not a formal body and therefore
unable to enter any non-disclosure agreements.
UNIRAS and probably others require NDAs from affected software vendors
before they share vulnerability information. It makes things easier
if you state upfront that you won't play such games.
On Thu, Jan 13, 2005 at 01:31:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 13 Jan 2005, Alan Cox wrote:
> >
> > It's not documenting the stuff Linus seems to be talking about which is
> > a public list ? Or does Linus want both ?
>
> I see myself as pretty extreme when it comes to my approach to security.
>
> And I actually distrust extremes. I'm at one end of the spectrum, and
> vendor-sec is at the other (I'm not even counting the head-in-the-sand
> approach as part of the spectrum ;). Knowing that, I'd expect that most
> people are somewhere in between.
>
> Which to me implies that while what I personally _want_ is total openness,
> that's not necessarily what makes the most sense in real life.
Gooood :)
> So I want to give people choice. I want to encourage openness. But hell,
> if we have a closed list with a declared short embargo that is known to
> not play games (ie clock starts ticking from original discovery, not from
> somebody elses embargo), that's good too.
>
> Let people vote with their feet. If vendor-sec ends up being where all the
> "important" things are discussed - so be it. We've not lost anything, and
> at worst a "kernel-security" list would be a way to discuss stuff that was
> already released by vendor-sec.
On my understanding we are about to win several things.
I rather prefer having vendorsec NOT deal with these issues because
it gives autonomy to the kernel team. It wont depend on "suspicious" criteria
of embargo's - but instead have a clear written policy for embargo's.
And the timeframe, as Alan says, has to be acceptable for the vendors to
generate their updates and run the QA process, otherwise things will
continue to be discussed at vendorsec.
Other than that, by not "wrapping" the fixes with non descritive changelogs,
we will have an official list of security problems. Hey, this is a serious
operating system.
Wrapping up fixes means "disclosure" for the better informed people
(the bad guys) who read the changesets, and means "lack of knowledge"
for the less informed - users who dont run the latest kernel and only
upgrade in case of public security issues (the majority of them?).
So the argument of "wrapping" up fixes for "better and safer code" is actually
very bad if you think about it.
Once we have that, there will be a "official" list of known issues.
Those MANY who ask
"I'm using v2.6.12 on my customized kernel and I can't upgrade to the latest
v2.6.20 kernel, which security bugs exist that I need fixed?"
Will have an easy answer.
This is better for the Linux kernel developers, better for vendors and better
for users.
* Florian Weimer ([email protected]) wrote:
> * Chris Wright:
>
> > To keep the conversation concrete, here's a pretty rough stab at
> > documenting the policy.
>
> Looks fine. Maybe you can add the following section?
>
> 3) Non-disclosure agreements
>
> The Linux kernel security contact is not a formal body and therefore
> unable to enter any non-disclosure agreements.
>
> UNIRAS and probably others require NDAs from affected software vendors
> before they share vulnerability information. It makes things easier
> if you state upfront that you won't play such games.
Fair point, I can add that easily.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
* Alan Cox ([email protected]) wrote:
> On Iau, 2005-01-13 at 20:55, Chris Wright wrote:
> > To keep the conversation concrete, here's a pretty rough stab at
> > documenting the policy.
>
> It's not documenting the stuff Linus seems to be talking about which is
> a public list ? Or does Linus want both ?
I got the impression that Linus was in favor of the private one,
despite his own leanings to absolute openness. I think a public one
(lkml notwithstanding) would be great for advisory announcements.
> > It is preferred that mail sent to the security contact is encrypted
> > with $PUBKEY.
>
> https:// and bugs.kernel.org ? You can make bugzilla autoprivate
> security bugs and alert people.
Yeah, I had thought about that too. Not a real bugzilla fan, but I'm
not tied to any particular method here.
> > well-tested or for vendor coordination. However, we expect these delays
> > to be short, measurable in days, not weeks or months. As a basic default
> > policy, we expect report to disclosure to be on the order of $NUMDAYS.
>
> Sounds good. $NUMDAYS is going to require some debate. My gut feeling is
> 14 days is probably the right kind of target for hard stuff remembering
> how long it takes to run QA on an enterprise grade kernel. If it gets
> too short then vendors are going to disclose elsewhere for their own
> findings and only to this list when they are all ready anyway which
> takes us back to square one.
>
> And many are probably a lot less - those nobody is going to rush out and
> build new vendor kernels for, or those that prove to be non serious can
> probably get bumped to the public list by the security officer within a
> day or two.
Yup, I think the severity and ease of exploit are part of the discussion
around disclosure timeframe.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Iau, 2005-01-13 at 22:12, Chris Wright wrote:
> > UNIRAS and probably others require NDAs from affected software vendors
> > before they share vulnerability information. It makes things easier
> > if you state upfront that you won't play such games.
>
> Fair point, I can add that easily.
Is it worth adding the stipulation up front about who sets release dates
and within what limit as well >
* Alan Cox ([email protected]) wrote:
> On Iau, 2005-01-13 at 22:12, Chris Wright wrote:
> > > UNIRAS and probably others require NDAs from affected software vendors
> > > before they share vulnerability information. It makes things easier
> > > if you state upfront that you won't play such games.
> >
> > Fair point, I can add that easily.
>
> Is it worth adding the stipulation up front about who sets release dates
> and within what limit as well >
Guess it's an open question. Do you agree with these basics bits?
- no guarantee
- attempt to work with reporter
- attempt to work with vendors
- goal of timely release
- retain final say
- within immediate to few weeks
Hard to put real time on it.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Sad, 2005-01-15 at 02:43, Chris Wright wrote:
> Guess it's an open question. Do you agree with these basics bits?
>
> - no guarantee
> - attempt to work with reporter
> - attempt to work with vendors
> - goal of timely release
> - retain final say
> - within immediate to few weeks
>
> Hard to put real time on it.
Its emphasising "release date set by linux-security not reporter" rather
than length - although length guidance is good.
* Alan Cox ([email protected]) wrote:
> On Sad, 2005-01-15 at 02:43, Chris Wright wrote:
> > Guess it's an open question. Do you agree with these basics bits?
> >
> > - no guarantee
> > - attempt to work with reporter
> > - attempt to work with vendors
> > - goal of timely release
> > - retain final say
> > - within immediate to few weeks
> >
> > Hard to put real time on it.
>
> Its emphasising "release date set by linux-security not reporter" rather
> than length - although length guidance is good.
Minor changes to capture this.
thanks,
-chris
DRAFT
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.
1) Contact
The Linux kernel security team can be contacted by email at
$CONTACTADR. This is a private list of security officers
who will help verify the bug report and develop and release a fix.
It is possible that the security team will bring in extra help from
area maintainers to understand and fix the security vulnerability.
It is preferred that mail sent to the security team is encrypted
with $PUBKEY.
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.
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
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.
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 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.
3) Non-disclosure agreements
The Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.
Chris Wright <[email protected]> said:
[...]
> DRAFT
[...]
> It is preferred that mail sent to the security team is encrypted
> with $PUBKEY.
Note that $PUBKEY might change, give pointers to the canonical places where
you can get the latest version (latest kernel source?). Perhaps indicate
where to find gpg and a gpg-aware mailer, or steps to encrypt a file and
send that over as an attachment. Need to clarify a mechanism by which they
can get back to you via encripted mail.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
hello,
i think security mailing list is a good idea. normally i would prefere a
full open list, but in some cases this could be the right way.
i have an additional idea. maybe it is useful to push the mails on the
list into publc space automaticly after a delay of $NUMDAYS+$MAX -
according to alans idea. with this little feature we could be sure, that
no security report will be 'forgotten'.
this 'public space' could be an open security list where anyone else is
able to comment reports, fixes and bugs.
bye,
patrick
On Thu, Jan 13, 2005 at 12:55:03PM -0800, Chris Wright wrote:
> To keep the conversation concrete, here's a pretty rough stab at
> documenting the policy.
>
> 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.
>
> 1) Contact
>
> The Linux kernel security contact is $CONTACTADDR. This is a private
> list of security officers who will help verify the bug report and develop
> and release a fix. It is possible that the security officers will bring
> in extra help from area maintainers to understand and fix the security
> vulnerability.
>
> It is preferred that mail sent to the security contact is encrypted
> with $PUBKEY.
>
> 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's already been made public.
>
> 2) Disclosure
>
> The goal of the kernel security contact 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. As a basic default
> policy, we expect report to disclosure to be on the order of $NUMDAYS.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
* Patrick Plattes ([email protected]) wrote:
> i think security mailing list is a good idea. normally i would prefere a
> full open list, but in some cases this could be the right way.
>
> i have an additional idea. maybe it is useful to push the mails on the
> list into publc space automaticly after a delay of $NUMDAYS+$MAX -
> according to alans idea. with this little feature we could be sure, that
> no security report will be 'forgotten'.
>
> this 'public space' could be an open security list where anyone else is
> able to comment reports, fixes and bugs.
We had actually discussed this. It's mainly a difficulty in managing
such an idea, nobody was opposed to it.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net