[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    Re: A Security Vulnerability in IP Multicast Filter...
From:       Valerie Bubb Fenwick <Valerie.Fenwick () Sun ! COM>
Date:       2008-06-20 18:17:32
Message-ID: Pine.GSO.4.64.0806201111520.12505 () ryoga
[Download RAW message or body]

On Fri, 20 Jun 2008, James Carlson wrote:

> Valerie Bubb Fenwick writes:
>>> Seems like a mistake that these sorts of bugs can't be viewed via
>>> bugs.opensolaris.org ...
>>
>> Hi Jim -
>>
>> It's because it's tagged as a security vulnerability.  Unfortunately, our process
>
> Yeah, I know how it ended up this way.  It still seems broken to me,
> as we send out these scary-looking notices to the field, and then the
> recipients (particularly those participating in the OpenSolaris
> effort, and thus presumably _developers_) can't get to the necessary
> background information.

Most of the information *should* be contained in the Sun Alert. If it
is not, please contact the author.

>> "security" - there's no distinguishing between "resolved & now okay to publish"
>> and "still in progress/don't publish yet".
>
> Right.  Even in that case, and even if we think that hiding this
> information is a good idea, it'd make sense to publish the "fixed in"
> information, as that's rather important for users.
>
> (Yes, in this case, the user could have deduced that bit of data from
> the alert, if read correctly.  That's beside the point.)

Right - but what is easy for you & I to decide is okay to publish, is
not so easy for a program to distinguish on a consistent & accurate basis.

The problem with security vuln issues is that there are many factors
in play - we're often coordinating with another vendor (or 10...)
and need to make sure we don't leak information prematurely.

>> It's tricky, even, to figure this out programitically, because we use a single CR
>> for tracking issues accross multiple releases - so something may be "resolved" for
>> one release, but not for all affected releases so we wouldn't be able to publish
>> yet. And, some affected releases may not get patched (for example, many years past
>> EOSL).  It is something we've started talking about, but no good solutions have
>> been proposed at this point.
>
> Fortunately (?), the MR data seem to be obscured in
> bugs.opensolaris.org anyway.

Yes, but due to how security vulnerabilities are handled and that integrations
may not necessarily happen in an expected order (especially when we are
coordinating across many releases, plus with many vendors) it becomes
less clear what can & cannot be published.  And even if we don't
publish the MR data, it would need to be used to determine ability  to
publish or not.

> Of course, those who are really curious can always go look at the
> Mercurial repository and examine the exact code changes made for the
> associated CR, so it's not as though we're hiding much information.
> We're just making it harder to use and driving up the cost by
> providing one-off answers to those who call and ask.  :-/

Most of the information should be in the Sun Alert. If it is not, then
we need to rework the Sun Alert.

It would be nice, though, if we could coordinate release of the CR data
with the Sun Alert - even if it were a manual process. That is something
several folks are talking about, but given we are in a transitional phase
for defect management, it may be better to handle in our new system of
record.

Valerie
-- 
Valerie Fenwick, http://blogs.sun.com/bubbva
Solaris Security Technologies,  Developer, Sun Microsystems, Inc.
17 Network Circle, Menlo Park, CA, 94025. 650-786-0461
_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]