[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230826214914.GA18442@openwall.com>
Date: Sat, 26 Aug 2023 23:49:14 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel, again
Hi Seth,
Thank you very much for your feedback. I wouldn't have guessed you feel
that way about some of this.
On Sat, Aug 26, 2023 at 02:31:29AM +0000, Seth Arnold wrote:
> On Sat, Aug 26, 2023 at 12:23:59AM +0200, Solar Designer wrote:
> > I'd appreciate any well-reasoned votes and constructive suggestions.
> > Maybe there are good ideas that didn't cross my mind yet.
>
> I think we'd all be better served to wait until next year before we try to
> make changes. Some additional space would probably do everyone some good.
Yet you suggest specific changes below. Do you mean waiting until next
year before making written policy changes yet changing the way we
actually work sooner, or do you intend your suggestions for next year?
> For my own part, I was frustrated getting a dozen emails about the policy
> and deadlines and folks saying "we don't even have a fix yet please back
> off" etc over and over and over again. There were usually more emails
> about the policy than about the issue.
Usually, maybe - for less important issues such as most of the syzkaller
stuff you mention. However, for StackRot there were so many messages on
the actual issue that even the significant number of messages on the
policy was relatively much smaller. Of course, it could still be
annoying when people were working hard on getting the issue fixed.
> I can't speak for the others but
> perhaps if we, as a group, were less vocal about the policies on every
> single bug report it might have been easier to work together.
Yes, that would make it easier to work together. However, it wouldn't
work well for the kinds of disclosures we were getting to linux-distros
so far unless we decide and state in advance that Linux kernel issues
are exempt from our policies.
On the other hand, with the Linux kernel documentation edit, maybe we'll
start seeing linux-distros notified after s@k.o has fixes ready, and
maybe this will work well, and if so we can keep our policies. Perhaps
in that case we won't need to remind the reporters of the policies in so
many messages because there would be a lot less coordination left to do.
Waiting until next year to see how it goes makes sense to me.
> For every security issue in the kernel that gets a CVE and The Whole
> Process, I'm sure there's five or ten more that go unnoticed by the
> wider world. Trying to do The Security Process on the ones that come to
> light feels silly when there's far more issues that may allow privilege
> escalation that never get the theater treatment. While we can (and should)
> try to bring more of these to light we might also reduce the friction on
> the ones that do come to light.
>
> I was also annoyed with the endless stream of "I found a security bug in
> the kernel, give me a CVE!" that are a mangled syzkaller reproducer and
> no work to diagnose the problem or propose a patch.
I agree that following the process so strictly makes little sense when
it's just an arbitrary subset of the actual issues being found and
(hopefully) fixed (unfortunately, in other cases silently).
> If every syzkaller
> issue received a CVE automatically, we'd immediately remove the most
> noisome posts.
Is every syzkaller issue a vulnerability?
> Here's what I think would help the most, if we in the future try to get
> copied on reports "like the old days":
>
> - No replies from distros@ subscribers about list policies. None. distros@
> subscribers can and should feel free to engage about the bug, about
> testing, about concerns, etc. But none about the list policies.
>
> We all know that the kernel developers don't just sit on reports for
> six months before they're forced to take action by public posts. They
> want fixes in a timely fashion and they're doing the work to deliver
> fixes in a timely fashion.
>
> They publish their patches in public very soon after the work is
> complete which addresses your concern about the inboxes and mail
> servers being a jackpot of private vulnerabilities.
>
> We shouldn't harangue them about the policies.
However, the current policies require certain things from the reporter.
If we don't notify the reporter of this early on, we rely on them having
carefully read and understood the policies on their own, or else our
last-moment enforcement may come as a big unpleasant surprise to them.
Alternatively, we'd have to give up on the enforcement altogether.
I think a less unreasonable alternative to the above two options would
be (like I wrote above) to decide and state in advance that Linux kernel
issues are exempt from our policies.
> - Make it clear to all that distributions can apply fixes to their kernels
> as soon as patches are in publicly visible trees or mail lists. Trying
> to coordinate dates didn't work well: The kernel people don't want
> to hold off on publishing fixes for an arbitrary reason. The distro
> people have their own cycles for integrating patches, performing quality
> control, preferences to not publish updates on important holidays or
> weekends, etc.
>
> Let's just let the kernel developers work on fixes on their own schedule
> and whenever they go public, just go with it.
>
> We shouldn't try to coordinate dates.
The problem with this is that Linux kernel patches appearing "in
publicly visible trees or mail lists" tend not to have their security
relevance documented yet, and deliberately so, whereas "distributions
can apply fixes to their kernels" typically only along with documenting
the security relevance. Surely distributions can start "integrating
patches, performing quality control" as soon as the fixes are available
and privately known to them as being important to integrate ASAP, but
they'd have to delay publication of the update packages. This is how
it's been lately. Are you suggesting that distributions start to ignore
the kernel maintainers' preference on not disclosing the security
relevance publicly for a while? I doubt it, but then I don't see what
other change you might be suggesting. Please clarify.
> - Ask Red Hat's CNA to consider setting up an automatic CVE assignment
> process for syzkaller issues. (Red Hat's CNA is now serving as a Root
> CNA for FOSS issues in general, so it feels like a plausible place to
> put this process. Google runs syzkaller and has four CNAs, perhaps
> one of them would be a better fit. Maybe the Linux Foundation could
> run a CNA for this purpose. I'm not picky.)
This is an interesting suggestion. I think we'd first need to determine
whether this can be automated at all without ending up with CVEs
assigned in cases where they shouldn't have been per MITRE's guidelines
(e.g., when no security boundary is crossed in proper documented usage).
> We shouldn't indulge the very-low-effort-researchers who aren't putting
> in much effort but trying to get CVEs.
On one hand, I agree. On the other, if it were not just an arbitrary
subset of issues, what would matter most isn't the researchers' effort
nor intent, but the nature of the issues - are they in fact security
issues, are they important, are they actionable by distros within days.
"No" to any of these means the issue is best not handled in private, but
first it takes effort to determine this. Yes, it wastes our resources.
I do not have a solution I'd be entirely happy with, which is a reason
why we're having this discussion.
Alexander
Powered by blists - more mailing lists
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.
