Subject: bsd-cert (was: Re: firstname.lastname@example.org filtering)
To: Todd C. Miller <Todd.Miller@courtesan.com>
From: Steven M. Bellovin <email@example.com>
Date: 07/03/2002 08:50:22
In message <200207030512.g635CMXl027835@xerxes.courtesan.com>, "Todd C. Miller"
>I'm going to don my asbestos suit for a minute and suggest that
>what we could really use is a *BSD security list, akin to the Linux
>vendor-sec list. I think it makes sense to have a place where we
>can discuss security issues common to all the BSDs and not worry
>about what is or is not of specific interest to ChooseYouOwnBSD.
>This could take one of two forms:
> a) A list open only to the various security officers that gets
> advance warning of problems, CERT advisories, etc.. This allows
> for coordinating fixes but requires that list members not forward
> things off-list. In the past, such lists have been leaky.
> b) An open list. No advanced warning of problems would be posted.
> The list could still be used for coordination but I don't find
> this terribly compelling.
I strongly agree. I've been mulling the following scheme for the last
few days. Comments welcome; redistribution of this to the proper
lists in the other BSD arenas solicited.
It's in everyone's interest to secure all machines on the
Internet -- *BSD, Linux, even Windows
Security holes (and the relevant fixes) can be discovered by
It takes a bit of time for responsible developers to create,
test, and integrate a fix.
It's generally advisable to keep problem information quiet
for a *reasonable* amount of time while this is going on.
That said, there are a few people who have to know beyond the
The responsible developer who's actually going to do
The release engineers, if one of the systems involved
is going through a release cycle.
In some cases, the folks who run the official repositories --
a compromised distribution site could be a disaster.
The crucial instant is when fixes (source or binary) are available via
the public repositories. This has to be co-ordinated.
So -- I propose creation of "BSD-CERT", to be composed of the security
officers from the different groups, plus representatives of the release
Each organization decides for itself who is best-suited to
fix the problem, and who else should know.
*But* -- *any* redistribution, *including* to the appropriate
developer, is accompanied by a note to the mailing list.
In other words, I want accountability. Violation of this
rule -- i.e., passing on the warning without telling the other
members of BSD-CERT -- is grounds for immediate removal from the list.
Existence of problems is disclosed to BSD-CERT as soon as it's
known, to permit proper scheduling. Yes, this might be before a
fix is ready.
No one makes anything public until everyone has a fix ready,
as long as that isn't taking an "unreasonable" amount of time.
(I decline to define "reasonable".) But if someone is taking
too long, there's no choice -- sitting on vulnerabilites doesn't
The relevant mailing lists should be run by a neutral party.
There's just too much history, bad blood, and mistrust for it
to be hosted at FooBSD.org, etc. (I'm afraid that that does
exclude Wasabi Systems.)
Membership in the mailing list should be identifiable individuals,
and not titles like security-officer@FooBSD.org.