There seems to be some confusion in certain quarters as to the proper
procedure for reporting possible kernel security issues.
REPORTING-BUGS says send bug reports to the maintainer of that area of
the kernel. However, what about areas for which a maintainer is not
listed? (e.g. VM) It seems that some take that to mean send it
directly to Linus and if you don't hear something back quickly, release
an exploit to the wild.
So what is the preferred procedure and is it documented somewhere?
Should it be made more prominent?
Thanks for any information,
Steve Bergman
Steve Bergman wrote:
> There seems to be some confusion in certain quarters as to the proper
> procedure for reporting possible kernel security issues.
> REPORTING-BUGS says send bug reports to the maintainer of that area of
> the kernel.
Unfortunately my english is not on a par with this but this document
*needs* updating at every corner and after that the direct hyperlink to
this document on the kernel.org should be placed above links of the
kernel source (currently it is somewhere at the middle of the page). And
the note "please read before using vanilla kernel" should be in red. It
*seems* to me that there is a big cap between reality and this
document/common sense (in the days of heavily patched kernels and 2.6
devel. model). There should be several separate parts in this document:
for kernel developers, for distro makers, for "smart" users, for
"enthusiasts"....
regards,
Indrek
* Steve Bergman:
> So what is the preferred procedure and is it documented somewhere?
Contact your vendor. You are using vendor kernels, are you? 8-)
Horst von Brand wrote:
>Indrek Kruusa <[email protected]> said:
>
>
>>Steve Bergman wrote:
>>
>>
>>
>>>There seems to be some confusion in certain quarters as to the proper
>>>procedure for reporting possible kernel security issues.
>>>REPORTING-BUGS says send bug reports to the maintainer of that area of
>>>the kernel.
>>>
>>>
>>Unfortunately my english is not on a par with this but this document
>>*needs* updating at every corner and after that the direct hyperlink to
>>this document on the kernel.org should be placed above links of the
>>kernel source (currently it is somewhere at the middle of the page). And
>>the note "please read before using vanilla kernel" should be in red. It
>>*seems* to me that there is a big cap between reality and this
>>document/common sense (in the days of heavily patched kernels and 2.6
>>devel. model). There should be several separate parts in this document:
>>for kernel developers, for distro makers, for "smart" users, for
>>"enthusiasts"....
>>
>>
>
>Write something up, I'd be happy to help polishing English. And you'll find
>more helpers on LKML.
>
>
sorry, but... yes, it was meant as "I am ready to help" :) but
definitely I am not the right person to start to change this document. I
can assist as linux user who need some information about bug reporting
and how/why I should use sources from kernel.org at all. I have no idea
what is desired by kernel developers (obviously they need good reports
from informed users and less annoying traffic in LKML...maybe this
letter is similar, sorry) but I have seen that those old school
enthusiasts who are going to compile their custom kernel after every new
release or -ac - they are not happy 'cause something which was part of
their life (faster, smaller and maybe safer custom system) is now quite
hard to achieve. Explanation would be nice for them, maybe even in
kernel README.
thanks,
Indrek
Florian Weimer wrote:
>Contact your vendor. You are using vendor kernels, are you? 8-)
>
>
Actually I am having a discussion with a Pax Team member about how the
recent exploits discovered by the grsecurity guys should have been
handled. They clam that they sent email to Linus and Andrew and did not
receive a response for 3 weeks, and that is why they released exploit
code into the wild.
Anyone here have any comments on what I should tell him?
Thanks,
Steve Bergman
On Mon, 10 Jan 2005, Steve Bergman wrote:
> Florian Weimer wrote:
>
> > Contact your vendor. You are using vendor kernels, are you? 8-)
> >
>
> Actually I am having a discussion with a Pax Team member about how the recent
> exploits discovered by the grsecurity guys should have been handled. They
> clam that they sent email to Linus and Andrew and did not receive a response
> for 3 weeks, and that is why they released exploit code into the wild.
>
> Anyone here have any comments on what I should tell him?
>
I don't know what other people would do or what the general feeling on
the list is, but personally I'd send such reports to the maintainer and
CC lkml, if there is no maintainer I'd just send to lkml.
--
Jesper Juhl
El Mon, 10 Jan 2005 15:42:11 -0600 Steve Bergman <[email protected]> escribi?:
> Actually I am having a discussion with a Pax Team member about how the
> recent exploits discovered by the grsecurity guys should have been
> handled. They clam that they sent email to Linus and Andrew and did not
> receive a response for 3 weeks, and that is why they released exploit
> code into the wild.
They could have mailed to *THIS* mailing list, so anyone can make a patch.
Are you sure it's an exploit? My information was that grsecurity
wanted some of their 'hooks' added to recent kernels and it hasn't
happened. That's not a security problem, that's an application
problem.
On Mon, 10 Jan 2005, Steve Bergman wrote:
> Florian Weimer wrote:
>
>> Contact your vendor. You are using vendor kernels, are you? 8-)
>>
>
> Actually I am having a discussion with a Pax Team member about how the recent
> exploits discovered by the grsecurity guys should have been handled. They
> clam that they sent email to Linus and Andrew and did not receive a response
> for 3 weeks, and that is why they released exploit code into the wild.
>
> Anyone here have any comments on what I should tell him?
>
> Thanks,
> Steve Bergman
>
> -
> 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/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> They could have mailed to *THIS* mailing list, so anyone can make a patch.
And abandon the whole idea of coordinated disclosure? That would put
anyone using vendor kernels at a disadvantage (there would be a time gap
between the vulnerability being public and the vendor kernel being
released -- which happened anyway with uselib() but which doesn't
*always* happen).
-Barry K. Nathan <[email protected]>
* Jesper Juhl ([email protected]) wrote:
> On Mon, 10 Jan 2005, Steve Bergman wrote:
> > Actually I am having a discussion with a Pax Team member about how the recent
> > exploits discovered by the grsecurity guys should have been handled. They
> > clam that they sent email to Linus and Andrew and did not receive a response
> > for 3 weeks, and that is why they released exploit code into the wild.
> >
> > Anyone here have any comments on what I should tell him?
> >
> I don't know what other people would do or what the general feeling on
> the list is, but personally I'd send such reports to the maintainer and
> CC lkml, if there is no maintainer I'd just send to lkml.
Problem is, the rest of the world uses a security contact for reporting
security sensitive bugs to project maintainers and coordinating
disclosures. I think it would be good for the kernel to do that as well.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
El Mon, 10 Jan 2005 16:19:01 -0800 "Barry K. Nathan" <[email protected]> escribi?:
> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> > They could have mailed to *THIS* mailing list, so anyone can make a patch.
>
> And abandon the whole idea of coordinated disclosure? That would put
> anyone using vendor kernels at a disadvantage (there would be a time gap
> between the vulnerability being public and the vendor kernel being
> released -- which happened anyway with uselib() but which doesn't
> *always* happen).
Yes it wouldn't be "coordinated disclosure" but at least you'd get a patch
instead of a public exploit.
El Mon, 10 Jan 2005 16:40:02 -0800 Chris Wright <[email protected]> escribi?:
> Problem is, the rest of the world uses a security contact for reporting
> security sensitive bugs to project maintainers and coordinating
> disclosures. I think it would be good for the kernel to do that as well.
(somewhat OT..)
Perhaps it's just me, but i think it'd be nice that a new kernel version is
released every time a security issue is found.
Yes, vendors update their kernels themselves, but there's a *lot* of people
in linux who run kernel.org kernels, and it's hopefully to keep working
that way.
Those people can also update themselves their kernel, also true. But the
security issues found in linux are not announced anywhere but mailing list
and sites like slashdot. Many people who run kernels from kernel.org don't
read slashdot or mailing lists and don't that there's a need of updating their
kernels. A new kernel version every time a security issue is found would help
for those people, or at least a "security updates" section in kernel.org's
webpage. Right now there's no "official" way of announcing those updates, and
I think it's a serious lack for a OS which is so widely used.
* Diego Calleja ([email protected]) wrote:
> El Mon, 10 Jan 2005 16:40:02 -0800 Chris Wright <[email protected]> escribi?:
>
> > Problem is, the rest of the world uses a security contact for reporting
> > security sensitive bugs to project maintainers and coordinating
> > disclosures. I think it would be good for the kernel to do that as well.
>
> (somewhat OT..)
>
> Perhaps it's just me, but i think it'd be nice that a new kernel version is
> released every time a security issue is found.
I agree. I'd not mind seeing a full release, but at least a collection
of relevant patches. I used to keep such a list, and have discussed
bringing it back with some folks (just for the current stable 2.6.x).
I think there's some agreement that we could do better.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, Jan 10, 2005 at 05:09:18PM -0500, linux-os wrote:
> Are you sure it's an exploit? My information was that grsecurity
> wanted some of their 'hooks' added to recent kernels and it hasn't
> happened. That's not a security problem, that's an application
> problem.
Yes, exploit (although the severity is arguable). See the 2.6.10-ac7
portion of the changelog here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110523047925271&w=2
-Barry K. Nathan <[email protected]>
On Llu, 2005-01-10 at 16:46, Steve Bergman wrote:
> So what is the preferred procedure and is it documented somewhere?
> Should it be made more prominent?
Good question. The preferred procedure depends on your viewpoint on
disclosure
[email protected] is a cross vendor security list and a good place for
stuff. It will deal with both public and date embargoed security
information. security@[your-vendor] should work for most responsible
vendors and may be more appropriate if it involves a vendor kernel that
may have bugs not in the base tree.
For stuff in -bk kernel snapshots and the like that isn't in the
production kernels then I'd start by mailing Linus/(Andrew for -mm) or
the list.
Alan
* Alan Cox:
> [email protected] is a cross vendor security list and a good place for
> stuff.
Some people claim that vendor-sec is not trustworthy anymore because
it leaks information, based on the recent forged e-matters advisory.
Personally, I think the intent of the forgers was to discredit
vendor-sec. There's no hard no evidence that there is a systematic
leak (apart from the occasional blunders).
* Barry K. Nathan:
> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
>> They could have mailed to *THIS* mailing list, so anyone can make a patch.
>
> And abandon the whole idea of coordinated disclosure?
For local vulnerabilities? Get real.
Most users won't update anyway because they still believe that the
kernel team makes timely security releases, and they are safe as long
as they use the latest kernel.org release. The current process
doesn't protect them.
(I know, they should use vendor kernels instead.)
* Jesper Juhl:
> I don't know what other people would do or what the general feeling on
> the list is, but personally I'd send such reports to the maintainer and
> CC lkml, if there is no maintainer I'd just send to lkml.
Nevertheless, it would be good to have a designated security contact
just in case, when something is discovered that needs a more
coordinated form of disclosure. Death by a single IP packet in the
default configuration, for example.
Local privilege escalation (or even denial-of-service) is not really
relevant. We know from experience that Linux does not enforce local
account separation and won't do so for the forseeable future, and the
prudent don't rely on it.
On Mon, 10 Jan 2005, Barry K. Nathan wrote:
> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> > They could have mailed to *THIS* mailing list, so anyone can make a patch.
>
> And abandon the whole idea of coordinated disclosure? That would put
Not everyone agrees that that is the proper way to do things, some prefer
full disclosure.
Personally I'd prefer full disclosure on a public mailing list (copying
vendors, maintainers etc of course), so as many people as possible can get
to work on a fix as soon as possible. Keeping things secret doesn't speed
up the time to get a fix made.
--
Jesper Juhl
On Mon, 10 Jan 2005, Chris Wright wrote:
> * Jesper Juhl ([email protected]) wrote:
> > On Mon, 10 Jan 2005, Steve Bergman wrote:
> > > Actually I am having a discussion with a Pax Team member about how the recent
> > > exploits discovered by the grsecurity guys should have been handled. They
> > > clam that they sent email to Linus and Andrew and did not receive a response
> > > for 3 weeks, and that is why they released exploit code into the wild.
> > >
> > > Anyone here have any comments on what I should tell him?
> > >
> > I don't know what other people would do or what the general feeling on
> > the list is, but personally I'd send such reports to the maintainer and
> > CC lkml, if there is no maintainer I'd just send to lkml.
>
> Problem is, the rest of the world uses a security contact for reporting
> security sensitive bugs to project maintainers and coordinating
> disclosures. I think it would be good for the kernel to do that as well.
>
Problem is that the info can then get stuck at a vendor or maintainer
outside of public view and risk being mothballed. It also limits the
number of people who can work on a solution (including peole getting to
work on auditing other code for similar issues). It also prevents admins
from taking alternative precautions prior to availability of a fix (you
have to assume the bad guys already know of the bug, not just the good
guys).
--
Jesper Juhl
>Not everyone agrees that that is the proper way to do things, some prefer
>full disclosure.
>Personally I'd prefer full disclosure on a public mailing list (copying
>vendors, maintainers etc of course), so as many people as possible can get
>to work on a fix as soon as possible. Keeping things secret doesn't speed
>up the time to get a fix made.
But five people working on the same thing aiming to provide a patch (the
very same one, probably) is also no better; work could be saved.
Jan Engelhardt
--
ENOSPC
On Maw, 2005-01-11 at 17:05, Jesper Juhl wrote:
> Problem is that the info can then get stuck at a vendor or maintainer
> outside of public view and risk being mothballed. It also limits the
> number of people who can work on a solution (including peole getting to
> work on auditing other code for similar issues). It also prevents admins
> from taking alternative precautions prior to availability of a fix (you
> have to assume the bad guys already know of the bug, not just the good
> guys).
The evidence is that for the most part the bad guys don't know about the
bug and the majority of the bad guys are not skilled enough to write
some of the complex exploits. They also automate extensively so given an
exploit can make very fast very effective use of it. There is an entire
field of economics and game theory tied up in this as well as papers by
some in the field who look at computer security models this way.
If you are a member of the full disclosure camp then fine, but please cc
vendor-sec when you publish the hole just in case Linus loses the email
and so vendors know too and can plan appropriately.
Alan
* Jesper Juhl ([email protected]) wrote:
> On Mon, 10 Jan 2005, Chris Wright wrote:
> > Problem is, the rest of the world uses a security contact for reporting
> > security sensitive bugs to project maintainers and coordinating
> > disclosures. I think it would be good for the kernel to do that as well.
> >
> Problem is that the info can then get stuck at a vendor or maintainer
> outside of public view and risk being mothballed. It also limits the
> number of people who can work on a solution (including peole getting to
> work on auditing other code for similar issues). It also prevents admins
> from taking alternative precautions prior to availability of a fix (you
> have to assume the bad guys already know of the bug, not just the good
> guys).
That's not quite the case. The point of having a security contact is to
help coordinate timely public disclosure, not to sit on and mothball
info. In most projects it turns out to be helpful.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Llu, 2005-01-10 at 21:42, Steve Bergman wrote:
> handled. They clam that they sent email to Linus and Andrew and did not
> receive a response for 3 weeks, and that is why they released exploit
> code into the wild.
>
> Anyone here have any comments on what I should tell him?
They could have reported them to:
vendor-sec
cert
dfn-cert
any other cert like object
security@almost any linux vendor
but didn't. Nor it appears did they chase up their report.
On Tue, 11 Jan 2005, Alan Cox wrote:
> On Maw, 2005-01-11 at 17:05, Jesper Juhl wrote:
> > Problem is that the info can then get stuck at a vendor or maintainer
> > outside of public view and risk being mothballed. It also limits the
> > number of people who can work on a solution (including peole getting to
> > work on auditing other code for similar issues). It also prevents admins
> > from taking alternative precautions prior to availability of a fix (you
> > have to assume the bad guys already know of the bug, not just the good
> > guys).
>
> The evidence is that for the most part the bad guys don't know about the
> bug and the majority of the bad guys are not skilled enough to write
> some of the complex exploits. They also automate extensively so given an
> exploit can make very fast very effective use of it. There is an entire
> field of economics and game theory tied up in this as well as papers by
> some in the field who look at computer security models this way.
>
Of course there are downsides to full disclosure, but there are downsides
to controlled disclosure as well. We could argue that for ages, but even
if the arguments persuaded a few to move to a different 'camp' there's
still going to be two "camps" out there and there always will be.
This thread got started by a question about how to go about informing
people about security vulnerabilities so I think we should erhaps try to
provide some sensible information about how to go about that that can be
useful to people no matter what "disclosure camp" the agree with. How
about something like what I've written below as an addition to
REPORTING-BUGS or as a seperate REPORTING-SECURITY-BUGS document ?
> If you are a member of the full disclosure camp then fine, but please cc
> vendor-sec when you publish the hole just in case Linus loses the email
> and so vendors know too and can plan appropriately.
>
not informing vendors would be stupid, they should get told just as
everyone else.
If we added something like the text below to REPORTING-BUGS or a sepperate
document, then people would have an easier time finding out how to
properly report security sensitive bugs, no matter what disclosure camp
they belong to.
The text below is very much a draft, comments welcome.
*****
* REPORTING-BUGS
*****
The purpose of this text is to give information on how to report security
vulnerabilities, submit example exploit code and similar about the Linux
kernel.
For general bug reporting information, please see the REPORTING-BUGS
document in the root of the kernel source.
It is generally recognized that there exists two main views on
how security vulnerabilities should be reported - the "full disclosure"
and "coordinated disclosure" schools of thought.
This text gives advice on how to report the issue depending on what camp
you belong to.
Coordinated disclosure
-----
If you belong to the camp that believes that security vulnerabilities are
best handled initially by maintainers, developers and vendors so that they
get a chance to develop a fix before the public at large gets told about
it then here's how you should probably report the issue.
Send your bugreport to the maintainer of the code affected. If there is no
maintainer send it to the maintainer of the stable kernel series that it
applies to. You may choose to send it to the kernel series maintainer as
well in any case.
In most cases you want to also send the bugreport to the [email protected]
mailing list. This is a cross-vendor security list, and by sending your
mail there it should reach most of the security contacts at the major
Linux vendors.
If you are using a kernel from a vendor (as opposed to a kernel from
kernel.org) and the issue only applies to the vendor kernel, then you
should also copy the email to the security coordinator at your vendor
(usually [email protected] or similar). You may want to do this
in any case even if the bug is not secific to your vendors kernel.
To sum this up.
Your primary recipients should be:
- maintainer of code in question
- maintainer of stable kernel series
Your CC list should most likely include:
- [email protected]
- [email protected] (or equivalent)
If you choose this approach, then please allow some time to pass for the
maintainer/vendor to develop a fix - depending on the nature of the
vulnerability, 14-30 days seems adequate before you publish the
information in a larger forum. Also, please do follow up on your
submission, make sure it's recieved and acted upon.
Full disclosure
-----
If you belong to the camp that believes that information about security
vulnerabilities should be made public broadly and with as many details as
possible as fast as possible, then we request that you, in addition to
whatever full disclosure mailing lists you are going to submit to, send a
copy of your report to the maintainer of the code, the stable kernel
series maintainer, [email protected] (so the vendors get a fair chance to
react to the public information on an even footing with everyone else),
[email protected] (so the kernel community at large gets a
chance to respond) and also to any subsystem or special interrest mailing
lists relevant to the code (if it's a net bug send a copy to netdev, if
it's a scsi bug send a coy to linux-scsi etc).
So, to sum up the recipients:
Your primary recipients should be:
- maintainer of code in question
- maintainer of stable kernel series
- the Linux Kernel Mailing List <[email protected]>
Your CC list should most likely include:
- [email protected]
- [email protected] (or equivalent)
- special interrest mailing lists relevant to the affected code.
--
Jesper Juhl
* Jesper Juhl ([email protected]) wrote:
>
> This thread got started by a question about how to go about informing
> people about security vulnerabilities so I think we should erhaps try to
> provide some sensible information about how to go about that that can be
> useful to people no matter what "disclosure camp" the agree with. How
> about something like what I've written below as an addition to
> REPORTING-BUGS or as a seperate REPORTING-SECURITY-BUGS document ?
Let's just bite the bullet...
===== REPORTING-BUGS 1.2 vs edited =====
--- 1.2/REPORTING-BUGS 2002-02-04 23:39:13 -08:00
+++ edited/REPORTING-BUGS 2005-01-10 15:35:10 -08:00
@@ -16,6 +16,9 @@ code relevant to what you were doing. If
describe how to recreate it. That is worth even more than the oops itself.
The list of maintainers is in the MAINTAINERS file in this directory.
+ If it is a security bug, please copy the Security Contact listed
+in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
+
If you are totally stumped as to whom to send the report, send it to
[email protected]. (For more information on the linux-kernel
mailing list see http://www.tux.org/lkml/).
===== MAINTAINERS 1.269 vs edited =====
--- 1.269/MAINTAINERS 2005-01-10 17:29:35 -08:00
+++ edited/MAINTAINERS 2005-01-11 13:29:23 -08:00
@@ -1959,6 +1959,11 @@ M: [email protected]
W: http://www.weinigel.se
S: Supported
+SECURITY CONTACT
+P: Security Officers
+M: kernel-security@{osdl.org, vger.kernel.org, wherever}
+S: Supported
+
SELINUX SECURITY MODULE
P: Stephen Smalley
M: [email protected]
* Jesper Juhl:
> Problem is that the info can then get stuck at a vendor or maintainer
> outside of public view and risk being mothballed.
The submitter can go public anyway. Most coordinators do not require
signing NDAs for submitters (some require them from software authors,
though).
A designated security contact would give submitters a choice: either
go public directly, or try something else first. And believe, some
vulnerabilities really need a tested fix which is published at the
time of disclosure (death by single packet, for example).
* Alan Cox:
> On Llu, 2005-01-10 at 21:42, Steve Bergman wrote:
>> handled. They clam that they sent email to Linus and Andrew and did not
>> receive a response for 3 weeks, and that is why they released exploit
>> code into the wild.
>>
>> Anyone here have any comments on what I should tell him?
>
> They could have reported them to:
> vendor-sec
vendor-sec's reputation apparently has been damaged in some circles as
the result of the fake e-matters advisory. Heise Online also
suggested that the exploit was leaked from vendor-sec ("a natural
conclusion").
> cert
CERT/CC shares vulnerability information with anyone who's paying
enough money (read the fine print). Probably that's not what the
submitters want.
> dfn-cert
DFN-CERT is certainly honored to be included in this list, but they
can only forward it to security@ at some vendors and probably
vendor-sec.
If you get stuck, asking someone who has published kernel
vulnerabilities previously what to do is also an option.
But in general, there are plenty of options besides trying to contact
just two kernel developers high up the food chain. Contacting the
subsystem maintainer is often a possiblity, too. Of course, it's no
good if the subsystem maintainer tells you to post it to a public
list. 8-/
On Tue, 11 Jan 2005, Chris Wright wrote:
> * Jesper Juhl ([email protected]) wrote:
> >
> > This thread got started by a question about how to go about informing
> > people about security vulnerabilities so I think we should erhaps try to
> > provide some sensible information about how to go about that that can be
> > useful to people no matter what "disclosure camp" the agree with. How
> > about something like what I've written below as an addition to
> > REPORTING-BUGS or as a seperate REPORTING-SECURITY-BUGS document ?
>
> Let's just bite the bullet...
>
No value in providing some info on what's the apreciated behaviour for
both the coordinated disclosure and full disclosure people of the world?
Both camps are going to continue to exist, and if you only provide
information on the prefered aproach for coordinated disclosure then you
have even less influence on how the full disclosure camp will spread the
info - if you provide some info for them as well, at least some are going
to follow it and then more of the proper kernel people will get notified
at once instead of finding out later via other channels. I still think
adding something along the lines of what I wrote to REPORTING-BUGS has
merrit.
--
Jesper Juhl
PS. Linus, adding you to CC since you're involved in the new thread on
more or less the same topic, so I thought you might be interrested in this
thread as well.
On Mer, 2005-01-12 at 12:33, Florian Weimer wrote:
> vendor-sec's reputation apparently has been damaged in some circles as
> the result of the fake e-matters advisory. Heise Online also
> suggested that the exploit was leaked from vendor-sec ("a natural
> conclusion").
For someone who has no actual information and is speculating wildly
perhaps. There are very good reasons that those who know something about
it are fairly sure it isnt the case.
Chris Wright wrote:
> +SECURITY CONTACT
> +P: Security Officers
> +M: kernel-security@{osdl.org, vger.kernel.org, wherever}
> +S: Supported
If you mean this in the sense of "choose one, then put it here",
this looks good. If you're suggesting multiple choices, to be
made by the bug reporter, I'm not so sure.
A single contact point, preferably with a human being that can
confirm that the message has been received and understood, and
indicate that there's now somebody taking care of it who knows
what to do (which may just be forwarding it to someone else or
some list, and monitoring the reaction), should be useful.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
* Werner Almesberger ([email protected]) wrote:
> Chris Wright wrote:
> > +SECURITY CONTACT
> > +P: Security Officers
> > +M: kernel-security@{osdl.org, vger.kernel.org, wherever}
> > +S: Supported
>
> If you mean this in the sense of "choose one, then put it here",
> this looks good. If you're suggesting multiple choices, to be
> made by the bug reporter, I'm not so sure.
Yeah, "choose one, then put it here." I've set up
[email protected].
> A single contact point, preferably with a human being that can
> confirm that the message has been received and understood, and
> indicate that there's now somebody taking care of it who knows
> what to do (which may just be forwarding it to someone else or
> some list, and monitoring the reaction), should be useful.
Agreed.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> Yeah, "choose one, then put it here." I've set up
> [email protected].
Any chance we could have that @kernel.org or @vger.kernel.org?
* Christoph Hellwig ([email protected]) wrote:
> On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > Yeah, "choose one, then put it here." I've set up
> > [email protected].
>
> Any chance we could have that @kernel.org or @vger.kernel.org?
Yeah sure, I'll ask.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Llu, 2005-01-17 at 23:26, Chris Wright wrote:
> * Christoph Hellwig ([email protected]) wrote:
> > On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > > Yeah, "choose one, then put it here." I've set up
> > > [email protected].
> >
> > Any chance we could have that @kernel.org or @vger.kernel.org?
@kernel.org would make a lot of sense given most other products/projects
are security@[projectsite] - [email protected] etc
* Alan Cox ([email protected]) wrote:
> On Llu, 2005-01-17 at 23:26, Chris Wright wrote:
> > * Christoph Hellwig ([email protected]) wrote:
> > > On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > > > Yeah, "choose one, then put it here." I've set up
> > > > [email protected].
> > >
> > > Any chance we could have that @kernel.org or @vger.kernel.org?
>
> @kernel.org would make a lot of sense given most other products/projects
> are security@[projectsite] - [email protected] etc
Makes perfect sense.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net