[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220515162740.GA20526@openwall.com>
Date: Sun, 15 May 2022 18:27:40 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: linux-distros list policy and Linux kernel
Hi,
This is a lengthy and belated message, yet I think is something we need
to discuss in here.
Context:
(linux-)distros list policy is generally to treat as public issues for
which a fix is public. For issues that haven't yet been brought to
(linux-)distros, this means they shouldn't be - and instead should be
brought to oss-security right away. For issues that have been on
(linux-)distros, this means an oss-security posting is to be made as
soon as a fix is made public.
This works well for most distros (where releasing a package update
generally implies documenting the update's known security relevance at
the same time) and for (linux-)distros list interactions with most
projects, with the major exception being the Linux kernel.
For Linux kernel maintainers, it is customary to post a fix technically
publicly but without indication of its security relevance, then work on
getting it merged into the various trees, and expect that its security
relevance wouldn't be clearly indicated publicly for a while.
I didn't keep track of statistics, but my impression was that in the
last few years for issues handled with linux-distros involved, the
maintainers usually reluctantly accepted linux-distros' way of handling
them - didn't insist that the reporter would post e.g. to netdev before
a "final" patch is ready, agreed on and honored coordinated release
dates, and didn't object to linux-distros members asking the reporter to
post about the issue to oss-security on the same day that a posting to a
Linux kernel list is made. I was grateful for that, especially knowing
that some of this is an inconvenience/overhead for the maintainers.
The handling was still often problematic (somehow way worse than for
other projects, in my impression), but that appeared to be because
discoverers/reporters were not familiar with the procedure and with our
expectations, or/and because our policy and thus expectations were
counter-intuitive for them (I admit this could mean that we were wrong
in having such unexpected policy). This also suggested that many didn't
fully read or didn't understand our published policy before posting to
linux-distros, which I tried to address by adding clarifications, some
emphasized in bold and eventually even in ALL CAPS (not as shouting, but
to make these parts less likely overlooked).
Somehow it seems to have gotten worse this year. In handling of an
issue in February, a reporter planned to ignore our policy after having
already shared an issue with linux-distros, and a list member from a
major distro tried to enforce the policy. In discussion that followed,
a kernel maintainer (someone I have a lot of respect for, and who I
think is also on the kernel security team?) said he had directed the
reporter to share the issue with linux-distros despite of the reporter's
explicit concerns and non-acceptance of the policy, expecting that
linux-distros members would be "reasonable" and won't actually enforce
the "unreasonable" policy (I don't recall the exact wording used, but
that's the gist of it). So it was not a case of something unexpected
being overlooked by someone new - it was a case of the policy being
deliberately violated by someone very experienced. (Moreover, we also
got accused of shouting with the ALL CAPS.)
linux-distros members and Linux kernel security team didn't arrive at an
agreement on how to handle further issues, planning to bring this up for
discussion on oss-security - which I am finally doing now. Meanwhile,
the handling was hectic - indeed, people felt discouraged from enforcing
the policy. Another kernel maintainer also mentioned he's no longer
directing people to linux-distros (which I find more reasonable than
coercing/expecting linux-distros not to enforce a published policy).
Question:
Should we address this incompatibility in desired handling of issues by
the distros vs. kernel teams, and how?
Options:
Off the top of my head, we can do one of:
0. Do nothing specific - let things work or fail on their own.
1. Adjust linux-distros policy to allow "embargoes" on publicly fixed
Linux kernel issues. (Only for Linux kernel, not for other projects.)
However, besides not posting to oss-security this probably means also
not releasing distro kernel updates until the "embargo" is over (when
the changes hit a stable tree maybe?), thus exposing most Linux users to
vulnerabilities that some attackers can infer from Linux kernel mailing
lists and git commits.
The current policy:
https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters
already includes an exception in:
"Please note that in case a fix for an issue is already in a publicly
accessible source code repository, we generally consider the issue
public (and thus you should post to oss-security right away, not report
the issue to (linux-)distros as we'd merely redirect you to oss-security
anyway and insist that you make the required posting ASAP). There can
be occasional (rare) exceptions to this, such as if the publicly
accessible fix doesn't look like it's for a security issue (e.g., if the
corresponding changes were initially made for unrelated reasons and were
only later realized to have fixed a non-public security issue) and not
revealing this publicly right away is somehow desirable. You'd have to
have very sound reasoning to claim an exception like this and be
prepared to lose your argument and if so to post to oss-security ASAP
anyway."
This currently talks about fixes that are already public at the time of
reporting to (linux-)distros, it requires "very sound reasoning", and it
allows (linux-)distros to insist that the issue be made public ASAP.
In my understanding, the Linux kernel folks want an exception like this
also for publicly fixing issues already being handled with linux-distros
involved, and to have the exception granted unconditionally with no way
for linux-distros not to agree to it in a given case. (Please correct
me if I misunderstand.)
2. Strictly enforce the policy as it is - and be in conflict with Linux
kernel security team, and handle fewer issues via linux-distros.
As a sub-option, also suggest that if a reporter or/and upstream does
not accept the policy, they can nevertheless use the list to establish
direct communication with interested distros - post a vague message like
"I found a [type, impact] vulnerability in the Linux kernel [versions,
subsystem], but I don't accept the list policy - please contact me
directly if you'd like to receive the details on my terms anyway."
Maybe with or without the clarifications I put in square brackets there.
3. Ask that Linux kernel issues not be reported to linux-distros at all.
This is unnecessarily limiting compared to option 2 above, but maybe not
so conflicting (just not using this specific medium for communication).
However, I think it won't work consistently - it would be too
unexpected by many (indeed, out of context it sounds plain ridiculous),
and linux-distros is referenced in older Linux kernel release trees.
More importantly, both teams actually want to communicate on issues
somewhere, and there isn't a good alternative currently.
4. Shut down the list. (What about the non-Linux distros list, then?)
I need to migrate the setup soon and ideally also update it later, so
shutting it down is as simple as not putting more effort into it. It's
been around for 11 years.
I don't like any of these options. Any other ideas? Any ways to make
option 1 more reasonable?
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.
