linux-kernel - Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Mar 2023 15:47:21 +0700
From:   Bagas Sanjaya <bagasdotme@...il.com>
To:     Willy Tarreau <w@....eu>, Vegard Nossum <vegard.nossum@...cle.com>
Cc:     Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Jiri Kosina <jkosina@...e.cz>,
        Solar Designer <solar@...nwall.com>,
        Will Deacon <will@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, Amit Shah <aams@...zon.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Laura Abbott <labbott@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Tyler Hicks <tyhicks@...ux.microsoft.com>
Subject: Re: [PATCH v3 0/7] Documentation/security-bugs: overhaul

On Mon, Mar 06, 2023 at 08:11:38AM +0100, Willy Tarreau wrote:
>   - I'm not seeing anywhere that the security list is *exclusively*
>     for kernel issues. That might explain why about once a week or so
>     we receive messages like "there's a bug in that userland tool" or
>     "we've found an XSS issue on your website". It's written that kernel
>     bugs should be reported to the security list but I think we should
>     strengthen that by adding "This list is exclusively used for Linux
>     kernel security reports, please do not report issues affecting any
>     other component there".

I think the wording would be "Please report security bugs against Linux
kernel to security@...nel.org list. Security bugs against userspace
applications should be reported to appropriate channels for affected
applications instead."

>   - it's quite frequent that reporters post from dummy addresses,
>     looking like randomly generated ones (we even had one looking
>     like a smiley). It doesn't help to communicate with them at all.
>     I can understand how some working as consultants for a customer
>     would want to avoid disclosing a particular relation between their
>     finding and their customer, but at least they should indicate how
>     they should be called. I.e. "call me Margarett" is not difficult
>     and simplifies exchanges when the address is "69236836@...mple.com".
>     And often we see at the end that they're willing to provide a real
>     name to be credited for the finding, so most likely starting with
>     this real name could be easier.
> 

Something like temporary addresses (à la maildrop or mail.gw)?

>   - it's more a discussion for the list itself, but the wording continues
>     to make one think that the reporter should expect the list members to
>     develop a patch, while in practise the first thing that's asked is
>     "since you've studied the problem well, do you happen to have a patch?".
>     And it happened a few times that in response we got "oops sorry, I
>     analysed it wrong, there's no issue there". I think the text should
>     emphasize more on encouraging submitters to complete their work with
>     a patch proposal (that's also helpful to confirm an analysis). And
>     conversely I think that reports for non-immediately exploitable issues
>     that are found by code analyzers (and almost always come without a
>     patch) should not be sent to this list and should be discussed and
>     addressed publicly instead. It's more efficient and allows more
>     knowledgeable participants to have their say on the root cause of
>     the problem and its possible solutions. That's of course not always
>     the case, but common sense should prevail here.

I think the wording would be "It is preferrable to have a proposed patch
for the bug you report. See
Documentation/process/submitting-patches.rst for details on how to
submit patches."

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)