Review of a secure software development process for glibc.

[Andrew Pinski]

On Fri, May 9, 2025 at 2:59 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> Community,
>
> We have been looking at how glibc is developed for a long time
> and as a community we have been improving that process with respect
> to security.
>
> The improvements are incremental, starting with a security policy, and
> then a security team and glibc CNA to handle security issues.
>
> Security is important. We implement the core C library on the GNU system,
> GNU/Linux systems, as well as many other systems that use Linux as the kernel.
> The project should be as secure as we can make it by default, while allowing
> users to harden it even further based on their requirements.
>
> I have written up a secure software development process (SSDLC) for glibc.
> Such a document should help us talk about our current development practices,
> where there are gaps in our security and how to improve them.
>
> While we're talking about secure software development, I want to be clear
> that I'm not talking about where to host such infrastructure, though the
> document I wrote does carry notes about CTI, Sourceware, and the GNU
> Project hosting. I'm happy to update the document based on feedback.
>
> I'm starting this thread not to discuss any hosting change, instead it is
> to discuss the what and the why around improving security regardless of
> hosting.
>
> I've written a broader document about the GNU Toolchain as a whole to see
> if any security requirements from the top-level would apply to glibc:
> https://sourceware.org/glibc/wiki/SSDLC
>
> The "What is being suggested and why?" applies broadly to all our
> security work, and I encourage you to read the top-level document for
> context.
>
> This document is glibc specific:
> https://sourceware.org/glibc/wiki/SSDLC/Policy/glibc


There seems to be contradictory information there.
Service isolation for sourceware: "Partially. Via containers and VMs,
but all on a single primary system."

But then later on under `Tasks/Service`:
"No. Process isolation only. High-availability via non-authoritative mirrors."

Which is it?

Note I think this document is less about security but more about how
"do I push CTI/LF".
If we want to talk about security of glibc sources, we need to step
back and think about the model of submitting patches and approvals.
That is talk about forges and how git write access should look like.
Right now signing up to become a glibc maintainer is just sending out
an email and get approves. Once someone gets approval for write access
they could push anything. That does require a lot of trust yes but
that is what security is all about. So going to forge style, the trust
chain is more explicit of who approved things, etc. Rather the current
model of adding Reviewed by manually.

Thanks,
Andrew

>
> The specifics here are about glibc and defining what we expect from the
> infrastructure, developer end points, and our process, and how that
> creates something that is sustainably secure and what services we need
> for that process.
>
> Some of the items in the writeup are the same as in Mark's writeup in
> "Suggested secure development policies for projects"
> https://sourceware.org/cyber-security-faq.html, but structured
> into NIST SP 800-218-based buckets and applied specifically to glibc.
>
> Please have a look through the documents and provide any feedback.
>
> --
> Cheers,
> Carlos.
>