[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 May 2022 09:41:37 -0700
From: Igor Seletskiy <i@...udlinux.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel
My vote would be for #1
Linux kernel is a huge ecosystem in its own right with many vested
players. They arrived at their way of handling security issues, and
overall doing a good job. It will be really hard to change that
ecosystem from the outside. This would make #2 very similar to #3 in many
cases.
On the other hand, the linux-distros mailing list is very valuable for the
participating distros (at least it is very valuable for CloudLinux OS), and
losing it as a resource would be dreadful for us. So would be losing only
part of the information related to the Linux kernel. As such I don't like
either #3 or #4.
I also don't like #0, as it seems we have a fairly concrete case to deal
with, and it can be dealt with explicitly using #1.
Regards,
Igor Seletskiy | CEO
CloudLinux OS <https://cloudlinux.com/cloudlinuxos> | KernelCare
<https://kernelcare.com> | Imunify360 <http://imunify360.com/> |
AlmaLinux <https://almalinux.org>
On Sun, May 15, 2022 at 9:28 AM Solar Designer <solar@...nwall.com> wrote:
> 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.
