Re: Security web page

[Bdale Garbee <bdale@gag.com>]

In article <m0xHXOv-000DK5C@landru.math.uwaterloo.ca> you wrote:

: One thing that hasn't been discussed is what information is provided on 
: the pages.  My personal feeling is that enough information to understand 
: the bug be provided so one knows whether it affects them. On the other hand
: that is often enough to exploit the bug and our pages are rather high 
: profile to be listing our own weaknesses.

I work for Hewlett-Packard by day, in a small division that builds electronic 
test equipment... but my job causes me to be in contact with various folks who 
are involved with computer and network security issues around the company.

I asked one of the folks who helps write security advisories for HP, and who
spent part of the day at my house yesterday getting Debian installed on his 
Omnibook, for his thoughts on this subject.  Here's what he said:

> Funny, we had a similar discussion in the security team just a little while
> ago, with the discussion centering around why non-disclosure was the right
> answer for hp-ux.  What we came down to was this (the statement has been
> expressed to non-HP people since then, so I'd wager it could be used):
> 
>     We understand that there are sharp differences of opinion about whether
>     or not to make security defect details public. We also understand that
>     making this information public in the expectation that it will
>     ultimately improve security has a long tradition in the Unix(tm)
>     community. We also recognize that there are advantages in some
>     situations to making this information public, including the ability
>     for system administrators to assess the severity of the defect for
>     themselves, possibly to devise their own fixes, and to develop tests
>     to confirm that the vulnerability is fixed. 
> 
>     However, we feel that when the source code is not generally available
>     the likely harm in making the details of security defects public
>     outweighs the likely gains. 
> 
> In short, so long as Linux continues to make source available for packages,
> I would be completely in favor of full disclosure.  This is especially true
> if users continue to be the sort that do their own kernel tweaking.  If you
> do choose full disclosure, then you probably want a distribution list to
> which people can subscribe in order to be informed of defects as they are
> discovered.  Bugtraq can have a lot of noise, so it probably wants to be
> it's own list.  The HP security bulletin mailing list is one of (if not the)
> largest mailing list run by WTEC.
> 
> Personally, I would think that a page giving the severity level, workaround,
> and patch (if any) would be a great service to the linux community.   If
> HP-UX source were generally available, I believe we would practice full
> disclosure.  Then again, our customers have indicated (with their purchasing
> dollars) that they are not interested in hacking on HP-UX, but would rather
> that we did it for them.

I find myself agreeing with this assessment... I think the only right answer
for an open system like Debian is to be very open with security vulnerability
and solution information.  The notion of a debian-bugtraq list (that name
would work for me, but might be too obscure for our user base?) to use as
an annoucement vehicle for changes in the security web pages has merit.

Bdale


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .