oss-security - Re: linux-distros membership

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 22 Jan 2014 11:51:39 +0100
From: rf@...eap.de
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros membership

>>>>> "SD" == Solar Designer <solar@...nwall.com> writes:

Hi Alexander,

thanks a lot for taking the time for this detailed reply.

    SD> Hi Roland, On Mon, Jan 20, 2014 at 05:36:27PM +0100,
    SD> rf@...eap.de wrote:
    >> >>>>> "Yves" == Yves-Alexis Perez <corsac@...ian.org> writes:
    >>
    >> Thanks again Yves. Unfortunately this doesn't help me with
    >> getting the timely reports about kernel security bugs from the
    >> linux-distros list. Can somebody, who knows the details of the
    >> process, please answer what we need to do, to get on the list?

    SD> Given that you seem to be interested only in Linux kernel
    SD> vulnerabilities, I think you're overestimating the value that
    SD> being on linux-distros will provide to you.  There are more
    SD> Linux kernel vulnerabilities being disclosed on oss-security
    SD> right away (yes, in public) than those that pass through
    SD> linux-distros first.  Yet you were not on oss-security until
    SD> after you've posted the request to join linux-distros a week
    SD> ago.  Did you not actually care?  Or was someone else from
    SD> Qlustar subscribed?

Yes, we definitely care. So far, we took the info from the Debian and
Ubuntu related security advisories or from info on the lists of the
software projects we additionally/differently provide (as compared to
Debian/Ubuntu). I must admit, I didn't even know about the oss-security
list (sorry).

    SD> Asking to join linux-distros before you've been on oss-security
    SD> for a while (and preferably, having contributed to the
    SD> discussions in here) is putting the cart before the horse.

I understand your point of view, but our users (and we) probably won't
care too much about the order of cart and horse. They just need timely updated
software :-)

    SD> I did not count them carefully, but I think there are relatively
    SD> more non-kernel vulnerabilities passing through linux-distros
    SD> (than kernel ones).  Actually, it might be the same ratio as on
    SD> oss-security, with the difference being that on oss-security
    SD> you're not unnecessarily exposed to additional sensitive info.

I'm sure there will be other stuff than kernel important for us to know
as well. Even for the packages that we just redistribute from upstream
(by far the majority) there can be situations that we don't want to
wait for an announced upstream package fix. Having the info before that
will allow us testing proposed fixes earlier and possibly prevent damage.

    SD> Unfortunately, we don't currently have a sub-list for just Linux
    SD> kernel, and if we set one up it might not work all that well (we
    SD> already saw some confusion with having distros and
    SD> linux-distros; adding a third list might make it worse).

    SD> I found Qlustar security advisories here:

    SD> https://www.qlustar.com/security-advisories

    SD> This is great, although I guess in "a Ubuntu/Debian based
    SD> distro" there are many more vulnerabilities being discovered.
    SD> How do you choose which packages to issue advisories for?  Are
    SD> they possibly the packages that differ from Ubuntu/Debian (that
    SD> is, that have your customizations)?

Exactly. Qlustar is a distro designed for a special purpose
(HPC/Storage/Cloud) clustering and 99% of the binary packages are simply
redistributed from upstream. It's only the remaining 1% we take care of
ourselves. Also note that for our kernels, we compile only stuff that's
relevant for clusters, so a lot of security issues don't affect them.

    SD> At first glance, it appears that about one half of your
    SD> advisories are about the kernel.

Correct, because that's the most concerned (with respect to security)
package where we differ from upstream.

    SD> Would having about 7 days of advance notice (and at most 19 on
    SD> some occasions, per list policy) on a small subset of Linux
    SD> kernel vulnerabilities be of much help in preparing update
    SD> packages?

Well it's better than nothing, but I'm pretty sure there will be cases
where it will be too late. 

    SD> Would it significantly reduce the window of exposure for your
    SD> users?  e.g., reducing it from 8 days to 1 day is significant,
    SD> but from 30 days to 23 days is much less so.

What exactly do you mean by advance notice anyway? Advance of what?
Can't tell without knowing that.

    SD> As to "the details of the process", we don't currently have it
    SD> fully formalized.  We did have a simple process for accepting a
    SD> subset of old vendor-sec members into the distros and
    SD> linux-distros lists, but after that point I'm afraid we never
    SD> arrived at a decision on whether we should introduce a
    SD> voting/vouching process like vendor-sec had.  Instead, we had a
    SD> few discussions in here, like the one we're having now due to
    SD> your request.  There were several membership requests that I
    SD> think fell in the grey area, and I think yours does too: it's
    SD> not unreasonable, but it fails to convince me that Qlustar being
    SD> on linux-distros would likely significantly benefit the users of
    SD> your distro.  Is anyone else in here convinced?  (Genuine
    SD> question.)

    SD> Among the criteria we do have is the distro issuing timely
    SD> security updates and advisories.  Qlustar appears to do that,
    SD> although only for a subset of packages,

See above. Note that even if we don't put out a security advisory for them,
upstream fixes for stuff unrelated to Qlustar's purpose still are
available from our repo latest a couple of days after the upstream
announcement.

    SD> and I'm unsure how timely the updates are (e.g., if they're late
    SD> by 30 days, then reducing that by ~7 days doesn't help all that
    SD> much, as in the example above).

I agree with your example, but such delays don't happen with us.

    SD> Of the distros currently on the list, I find it most difficult
    SD> to justify (to myself) the membership of MontaVista and Wind
    SD> River.  (This was discussed before.)  Qlustar appears similar in
    SD> some aspects, but without a track record (known to me) of having
    SD> participated in the security community (which both MontaVista
    SD> and Wind River have).  In fact, I don't recall hearing about
    SD> Qlustar before (and Google web search finds very little, too).

Well we're pretty new and just getting more widespread ..

    SD> Are Qlustar's security updates (not just security advisories)
    SD> publicly available?

Yes, all our packages are publicly available from our website.

    SD> Let's discuss.  Roland, your own opinion counts too - it's not
    SD> just you trying to justify this to the rest of us, but it's us
    SD> all (including you) trying to arrive at what's deemed the best
    SD> decision.  We have a community here on oss-security, and you're
    SD> welcome to join us and participate in discussions regardless of
    SD> whether Qlustar gets on linux-distros or not.

Fine.

    SD> Meanwhile, please add Qlustar info to:

    SD> http://oss-security.openwall.org/wiki/vendors

Will do.

    >> >> >> I hope this is the right place to ask for inclusion of a
    >> >> >> Qlustar contact in the linux-distros list.

    SD> Yes, it is the right place.

Good, I'm glad about that :)

    >> >> >> Qlustar is a Ubuntu/Debian based distro targeted at
    >> >> >> HPC/Storage/Cloud clusters. We use our own kernels
    >> >> >> (typically based on vanilla) since many years, but have the
    >> >> >> need to supply timely security fixes to our users. So far
    >> >> >> we have to wait for other distros to come out with their
    >> >> >> announcements and then start analyzing the fixes they have
    >> >> >> done. This leaves us/our users with a vulnerability window
    >> >> >> that is way too large,
    >> >>
    >> >> > I can't speak for Ubuntu, but you're welcome to participate
    >> >> > in the Debian security effort.
    >> >>
    >> >> thanks a lot for your offer. Could you explain a little more
    >> >> what participation in the Debian security effort would mean?
    >> >> Note that the issue I currently have is mostly about kernel
    >> >> fixes and we don't use Debian nor Ubuntu kernels.

    Yves> Most of the documentation can be found in the secure-testing
    Yves> repository [1] and on the Debian wiki [2].
    >>
    Yves> [1]:
    Yves> http://anonscm.debian.org/viewvc/secure-testing/doc/narrative_introduction?view=markup
    Yves> [2]: https://wiki.debian.org/Teams/Security

    SD> Alexander

    SD> P.S. Somehow your replies arrive as entirely new messages, not
    SD> as replies to whatever message you're replying to.  They lack
    SD> proper In-Reply-To header.  It'd be helpful if you correct that
    SD> (for further replies), as it is needed for proper threading in
    SD> the list archives.  Normally, In-Reply-To is set if you simply
    SD> use your mail program's "reply" feature.  I don't know why this
    SD> was not happening for you.

My bad. When writing my first message I wasn't subscribed to the list
yet, so I had to answer with copy/paste. Should work OK now.

Roland
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.