Re: [6.12.y-cip][PATCH v2] Add SECURITY.md for the CIP kernel

[Pavel Machek <pavel@nabladev.com>]

[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]

Hi!

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This describes at which time which ares of the CIP kernel are handled by
> the CIP security team and how to report vulnerabilities to it. It
> furthermore state the this projects falls under the LF stewardship
> framework.
> 
> As the original kernel documentation already contains a reporting guide,
> leave a note there which one applies to CIP kernels.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---

Okay, so poor reporter starts here...

[A--starting palce]
> @@ -3,6 +3,12 @@
>  Security bugs
>  =============
>  
> +.. note::
> +
> +   If you identified a vulnerability that only affects a CIP kernel, please
> +   instead follow the reporting process described in SECURITY.md that can be
> +   found in the top-level directory.
> +

Goes here:

> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 0000000000000..f39a0178338ee
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,37 @@
> +# Security Policy
> +
> +This project is supported under the Linux Foundation CRA stewardship framework,
> +as described at https://www.linuxfoundation.org/security. Security

I would not mind " " before ".", so that link can be clicked (here and elsewhere).

> +vulnerabilities should be reported through the mechanisms described below,
> +which we will coordinate with our CRA steward. For actively exploited
> +vulnerabilities and severe incidents that may require CRA escalation, please
> +use the project’s emergency security reporting mechanisms as
> appropriate.

...and follows link

Sending an email to security@DOMAIN where DOMAIN is the domain of the
project/foundation. For example, Linux kernel security vulnerabilities
should be reported to security@kernel.org as described in the [[Linux
kernel security bugs page]]. In some cases, different email
address(es) other than “security” will be recommended.

Link makered [[]] will send him straight back to [A--starting palce].

Well, problem does not arise if someone goes through whole SECURITY.md first.

> +## Security Context
> +
> +Open source software can be used in various contexts that may go far beyond
> +what it was originally designed and also secured for. Therefore, we describe
> +here what the CIP kernel maintenance is particularly covering and what is out
> +of scope.
> +
> +Unlike the upstream kernel, the CIP kernel is maintained with the focus on
> +architectures and configurations defined by the CIP project members, see
> +https://gitlab.com/cip-project/cip-kernel/cip-kernel-config. Vulnerabilities
> +found in code paths not covered this way are considered out of scope.
> +Furthermore, vulnerabilities that are affecting the upstream Linux kernel as
> +well are in the responsibility of the kernel security team, see
> +https://www.kernel.org/doc/html/latest/process/security-bugs.html. In scope for
> +the CIP kernel are issues caused by patches not found in the corresponding
> +stable kernel (linux-6.12.y-cip vs. linux-6.12.y) or that are related to
> +missing backports after the corresponding stable kernel went end-of-life.
> +
> +## Reporting a Vulnerability
> +
> +Please DO NOT report any potential security vulnerability via a public channel
> +(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
> +security@cip-project.org via email. Please provide a detailed description of
> +the issue, the steps to reproduce it, the affected versions and, if already
> +available, a proposal for a fix. You should receive a response within 5 working
> +days. If the issue is confirmed as a vulnerability by us, we will request a
> +CVE, publish the fix and give credits for your report if desired. This project
> +follows a 90 day disclosure timeline.

AFAICT what we are saying here is that:

bugs in -cip backports in 5.10/6.1/6.12 -> security@cip-project.org
other bugs in -cip for 5.10/6.1/6.12 -> security@kernel.org
all the bugs in 4.4/4.19 -> security@cip-project.org

That means that SPARC bug in 4.4-cip, for example, goes to us.

Good news is, that we have CRA contact at linux foundation that can
help, if we need help. Ok.

I still believe we should publish GPG key for
security@cip-project.org. I know sharing private keys is usually
no-no, but that still seems better than potentially no encryption at
all.

I guess I'm ok with the patch.

Best regards,
								Pavel


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]