[PATCH] Add SECURITY.md for the CIP kernel

[PATCH] Add SECURITY.md for the CIP kernel

[Jan Kiszka]

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.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

First proposal. Please review and provide feedback. If we all agree, 
this should be merged into all CIP kernel branches.

 SECURITY.md | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 SECURITY.md

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
+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.
+
+## 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.
-- 
2.47.3

Re: [PATCH] Add SECURITY.md for the CIP kernel

[Jan Kiszka]

Sorry for double-posting - connectivity issues suggested it wasn't sent.

Jan

On 15.09.26 10:34, Jan Kiszka wrote:
> 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.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> First proposal. Please review and provide feedback. If we all agree, 
> this should be merged into all CIP kernel branches.
> 
>  SECURITY.md | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 SECURITY.md
> 
> 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
> +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.
> +
> +## 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.

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] Add SECURITY.md for the CIP kernel

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3414 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.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> First proposal. Please review and provide feedback. If we all agree, 
> this should be merged into all CIP kernel branches.

So... latest kernel already has
Documentation/process/security-bugs.rst as an entry point for security
bugs. 6.1 and 5.10 have Documentation/admin-guide/security-bugs.rst .

security-bugs.rst tells people to basically do normal bug report,
Cc-ing security@kernel.org, avoiding mailing list cc. That will be
unencrypted email, and they offer up-to 7 to 14 days of embargo.

The "linux-distros" mailing list is mentioned there.

> +++ 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
> +vulnerabilities should be reported through the mechanisms described below,
> +which we will coordinate with our CRA steward. For actively
> exploited

I don't believe all readers will know what "CRA" means in this
context. I'm not sure, for example, and knowledge will be even lower
for people outside EU.

> +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.

Ok, so here's security@cip-project.org , and we make promises
different from what security@kernel.org promises (90 days vs. 7 days,
for example). I'd suggest adopting policy from security-bugs.rst with
different email address.

Plus there's cra-steward-something@linuxfoundation.org, I assume.

I guess I'm quite confused at this point, and whoever hit a security
problem is confused, too.

First, what do we people to do? My understaning is:

if bug is actively exploited:
       mail cra-steward-something@linuxfoundation.org
elif there's misconfigured gitlab, someone stolen my passwords, malware in the repositories:
       mail cra-steward-something@linuxfoundation.org
elif bug is in -cip specific code in kernel:
       mail security@cip-project.org
elif bug is in 4.4-cip or 4.19-cip:
       mail security@cip-project.org
elif bug is in 5.10-cip or newer:
       mail security@kernel.org
else:
       # there may be bugs in self-maintained kernels, in parts we
       # don't support, such as arch/s390x. What to do with those?
       # Can we document we just don't care? Or do we need to handle
       # them?
       mail security@cip-project.org

Does that make sense? We probably should include real address for
cra-steward-something@linuxfoundation.org here.

Best regards,
								Pavel

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

Re: [PATCH] Add SECURITY.md for the CIP kernel

[Jan Kiszka]

On 23.09.26 23:15, Pavel Machek wrote:
> 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.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> First proposal. Please review and provide feedback. If we all agree, 
>> this should be merged into all CIP kernel branches.
> 
> So... latest kernel already has
> Documentation/process/security-bugs.rst as an entry point for security
> bugs. 6.1 and 5.10 have Documentation/admin-guide/security-bugs.rst .
> 
> security-bugs.rst tells people to basically do normal bug report,
> Cc-ing security@kernel.org, avoiding mailing list cc. That will be
> unencrypted email, and they offer up-to 7 to 14 days of embargo.
> 
> The "linux-distros" mailing list is mentioned there.

All clear - what is your concrete proposal for us? We are not upstream.

> 
>> +++ 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
>> +vulnerabilities should be reported through the mechanisms described below,
>> +which we will coordinate with our CRA steward. For actively
>> exploited
> 
> I don't believe all readers will know what "CRA" means in this
> context. I'm not sure, for example, and knowledge will be even lower
> for people outside EU.

This text is taken 1:1 from the LF template which we cannot modify here.
If you have legal or wording concerns, please follow up with suggestions
on the internal thread we had.

> 
>> +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.
> 
> Ok, so here's security@cip-project.org , and we make promises
> different from what security@kernel.org promises (90 days vs. 7 days,
> for example). I'd suggest adopting policy from security-bugs.rst with
> different email address.

We can adopt the disclosure timelines and explanations of the kernel
here. Concrete ideas what all fits for us are welcome.

> 
> Plus there's cra-steward-something@linuxfoundation.org, I assume.

This is internal.

> 
> I guess I'm quite confused at this point, and whoever hit a security
> problem is confused, too.
> 
> First, what do we people to do? My understaning is:
> 
> if bug is actively exploited:
>        mail cra-steward-something@linuxfoundation.org
> elif there's misconfigured gitlab, someone stolen my passwords, malware in the repositories:
>        mail cra-steward-something@linuxfoundation.org

These are our tasks, not the reporter's.

> elif bug is in -cip specific code in kernel:
>        mail security@cip-project.org
> elif bug is in 4.4-cip or 4.19-cip:
>        mail security@cip-project.org

Yep.

> elif bug is in 5.10-cip or newer:
>        mail security@kernel.org

Nope. We surely don't want reporters to go to the upstream list on our
downstream kernels. Unless they reproduced with 5.10.y as well.

> else:
>        # there may be bugs in self-maintained kernels, in parts we
>        # don't support, such as arch/s390x. What to do with those?
>        # Can we document we just don't care? Or do we need to handle
>        # them?
>        mail security@cip-project.org

When in doubt, report to us. That applies to us as well as to externals
that are unsure about where is the origin of the issue.

Jan

> 
> Does that make sense? We probably should include real address for
> cra-steward-something@linuxfoundation.org here.
> 
> Best regards,
> 								Pavel

-- 
Siemens AG, Foundational Technologies
Linux Expert Center