Re: [RFC] GCC Security policy

On 2024-02-12 10:00, Richard Biener wrote: GCC driver support is then to the extent identifying the inputs and the outputs. We already have -MM to generate a list of non-system dependencies, so gcc should be able to pass on inputs to the tool, which could then map those files (and the system

Re: [RFC] GCC Security policy

On Mon, Feb 12, 2024 at 2:35 PM Siddhesh Poyarekar wrote: > > On 2024-02-12 08:16, Martin Jambor wrote: > >> This probably ties in somewhat with an idea David Malcolm had riffed on > >> with me earlier, of caching files for diagnostics. If we could unify > >> file accesses somehow, we could make

Re: [RFC] GCC Security policy

On 2024-02-12 08:16, Martin Jambor wrote: This probably ties in somewhat with an idea David Malcolm had riffed on with me earlier, of caching files for diagnostics. If we could unify file accesses somehow, we could make this happen, i.e. open/read files as root and then do all execution as

Re: [RFC] GCC Security policy

On 2024-02-09 15:06, Joseph Myers wrote: Ideally dependencies would be properly set up so that everything is built in the original build, and ideally there would be no need to relink at install time (I'm not sure of the exact circumstances in which it might be needed, or on what OSes to e.g.

Re: [RFC] GCC Security policy

Hi, On Fri, Feb 09 2024, Siddhesh Poyarekar wrote: > On 2024-02-09 10:38, Martin Jambor wrote: >> If anyone is interested in scoping this and then mentoring this as a >> Google Summer of Code project this year then now is the right time to >> speak up! > > I can help with mentoring and reviews,

Re: [RFC] GCC Security policy

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: > > I think disallowing running as root would be a big problem in practice - > > the typical problem case is when people build software as non-root and run > > "make install" as root, and for some reason "make install" wants to > > (re)build or

Re: [RFC] GCC Security policy

On 2024-02-09 12:14, Joseph Myers wrote: On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: For privilege management we could add a --allow-root driver flag that allows gcc to run as root. Without the flag one could either outright refuse to run or drop privileges and run. Dropping privileges

Re: [RFC] GCC Security policy

On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote: > For privilege management we could add a --allow-root driver flag that allows > gcc to run as root. Without the flag one could either outright refuse to run > or drop privileges and run. Dropping privileges will be a bit tricky to > implement

Re: [RFC] GCC Security policy

On 2024-02-09 10:38, Martin Jambor wrote: If anyone is interested in scoping this and then mentoring this as a Google Summer of Code project this year then now is the right time to speak up! I can help with mentoring and reviews, although I'll need someone to assist with actual approvals.

Re: [RFC] GCC Security policy

Hi, On Tue, Aug 08 2023, Richard Biener via Gcc-patches wrote: > On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar wrote: >> >> On 2023-08-08 04:16, Richard Biener wrote: >> > On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches >> > wrote: >> >> >> >> FOSS Best Practices recommends

Re: [RFC] GCC Security policy

This is a great initiative I think. See reference to AdaCore's security email below (among Debian, Red Hat, SUSE) On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > FOSS Best Practices recommends that projects have an official Security > policy

Re: [RFC] GCC Security policy

Hello folks, Here's v3 of the top part of the security policy. Hopefully this addresses all concerns raised so far. Thanks, Sid What is a GCC security bug? === A security bug is one that threatens the security of a system or network, or might compromise the

Re: [RFC] GCC Security policy

On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote: > > Yeah, indicating scenarios that fall outside of intended guarantees should > > be helpful. I feel the exact text quoted above will be hard to decipher > > without knowing the discussion that led to it. Some sort of supplementary > > section

Re: [RFC] GCC Security policy

On 2023-08-16 11:06, Alexander Monakov wrote: No I understood the distinction you're trying to make, I just wanted to point out that the effect isn't all that different. The intent of the wording is not to prescribe a solution, but to describe what the compiler cannot do and hence, users must

Re: [RFC] GCC Security policy

On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote: > No I understood the distinction you're trying to make, I just wanted to point > out that the effect isn't all that different. The intent of the wording is > not to prescribe a solution, but to describe what the compiler cannot do and > hence,

Re: [RFC] GCC Security policy

> On Aug 16, 2023, at 3:53 AM, Alexander Monakov wrote: > >> ... >> Is "timing-safety" a security property? Not the way I understand that >> term. It sounds like another way to say that the code meets real time >> constraints or requirements. > > I meant in the sense of not admitting

Re: [RFC] GCC Security policy

On 2023-08-15 19:07, Alexander Monakov wrote: On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: Thanks, this is nicer (see notes below). My main concern is that we shouldn't pretend there's some method of verifying that arbitrary source code is "safe" to pass to an unsandboxed compiler, nor

Re: [RFC] GCC Security policy

> > Unfortunately the lines that follow: > > > >> either sanitized by an external program to allow only trusted, > >> safe compilation and execution in the context of the application, > > > > again make a reference to a purely theoretical "external program" that > > is not going to

Re: [RFC] GCC Security policy

On 2023-08-16 04:25, Alexander Monakov wrote: On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote: I'd prefer to reword this, as libgccjit was a poor choice of name for the library (sorry!), to make it clearer it can be used for both ahead- of-time and just-in-time compilation, and that

Re: [RFC] GCC Security policy

On 8/16/23 01:07, Alexander Monakov wrote: On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: Thanks, this is nicer (see notes below). My main concern is that we shouldn't pretend there's some method of verifying that arbitrary source code is "safe" to pass to an unsandboxed compiler, nor should

Re: [RFC] GCC Security policy

On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote: > I'd prefer to reword this, as libgccjit was a poor choice of name for > the library (sorry!), to make it clearer it can be used for both ahead- > of-time and just-in-time compilation, and that as used for compilation, > the host

Re: [RFC] GCC Security policy

On Tue, 15 Aug 2023, Paul Koning wrote: > Now I'm confused. I thought the whole point of what GCC is trying to, and > wants to document, is that it DOES preserve security properties. If the > source code is standards-compliant and contains algorithms free of security > holes, then the

Re: [RFC] GCC Security policy

> On Aug 15, 2023, at 8:37 PM, Alexander Monakov wrote: > >> ... >> At some point the system tools need to respect the programmer or operator. >> There is a difference between writing "Hello, World" and writing >> performance critical or safety critical code. That is the responsibility >> of

Re: [RFC] GCC Security policy

On Tue, 15 Aug 2023, David Edelsohn wrote: > > Making users responsible for verifying that sources are "safe" is not okay > > (we cannot teach them how to do that since there's no general method). > > Making users responsible for sandboxing the compiler is fine (there's > > a range of

Re: [RFC] GCC Security policy

On Tue, Aug 15, 2023 at 7:07 PM Alexander Monakov wrote: > > On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > > > > Thanks, this is nicer (see notes below). My main concern is that we > > > shouldn't pretend there's some method of verifying that arbitrary > source > > > code is "safe" to pass to

Re: [RFC] GCC Security policy

On Mon, 2023-08-14 at 09:26 -0400, Siddhesh Poyarekar wrote: > Hi, > > Here's the updated draft of the top part of the security policy with all > of the recommendations incorporated. > > Thanks, > Sid > > > What is a GCC security bug? > === > > A security bug is

Re: [RFC] GCC Security policy

On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > > Thanks, this is nicer (see notes below). My main concern is that we > > shouldn't pretend there's some method of verifying that arbitrary source > > code is "safe" to pass to an unsandboxed compiler, nor should we push > > the responsibility of

Re: [RFC] GCC Security policy

On 2023-08-15 10:07, Alexander Monakov wrote: On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: Does this as the first paragraph address your concerns: Thanks, this is nicer (see notes below). My main concern is that we shouldn't pretend there's some method of verifying that arbitrary source

Re: [RFC] GCC Security policy

> On Aug 15, 2023, at 10:07 AM, Alexander Monakov wrote: > > > On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > >> Does this as the first paragraph address your concerns: > > Thanks, this is nicer (see notes below). My main concern is that we shouldn't > pretend there's some method of

Re: [RFC] GCC Security policy

On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote: > Does this as the first paragraph address your concerns: Thanks, this is nicer (see notes below). My main concern is that we shouldn't pretend there's some method of verifying that arbitrary source code is "safe" to pass to an unsandboxed

Re: [RFC] GCC Security policy

On 2023-08-15 01:59, Alexander Monakov wrote: On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: There's no practical (programmatic) way to do such validation; it has to be a manual audit, which is why source code passed to the compiler has to be *trusted*. No, I do not think that is a logical

Re: [RFC] GCC Security policy

On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: > There's no practical (programmatic) way to do such validation; it has to be a > manual audit, which is why source code passed to the compiler has to be > *trusted*. No, I do not think that is a logical conclusion. What is the problem with

Re: [RFC] GCC Security policy

On 2023-08-14 17:16, Alexander Monakov wrote: On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: 1. It makes it clear to users of the project the scope in which the project could be used and what safety it could reasonably expect from the project. In the context of GCC for example, it cannot

Re: [RFC] GCC Security policy

On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: > 1. It makes it clear to users of the project the scope in which the project > could be used and what safety it could reasonably expect from the project. In > the context of GCC for example, it cannot expect the compiler to do a safety > check of

Re: [RFC] GCC Security policy

On 2023-08-14 14:51, Richard Sandiford wrote: I think it would help to clarify what the aim of the security policy is. Specifically: (1) What service do we want to provide to users by classifying one thing as a security bug and another thing as not a security bug? (2) What service do we

Re: [RFC] GCC Security policy

I think it would help to clarify what the aim of the security policy is. Specifically: (1) What service do we want to provide to users by classifying one thing as a security bug and another thing as not a security bug? (2) What service do we want to provide to the GNU community by the same

Re: [RFC] GCC Security policy

Hi, Here's the updated draft of the top part of the security policy with all of the recommendations incorporated. Thanks, Sid What is a GCC security bug? === A security bug is one that threatens the security of a system or network, or might compromise the

Re: [RFC] GCC Security policy

On 2023-08-11 11:12, David Edelsohn wrote: The text above states "bugs in these libraries may be evaluated for security impact", but there is no comment about the criteria for a security impact, unlike the GLIBC SECURITY.md document.  The text seems to imply the "What is a security bug?"

Re: [RFC] GCC Security policy

On 2023-08-11 11:09, Paul Koning wrote: On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote: On 2023-08-10 14:50, Siddhesh Poyarekar wrote: As a result, the only case for a potential security issue in all these cases is when it ends up generating vulnerable output for

Re: [RFC] GCC Security policy

On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar wrote: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: > >> Do you have a suggestion for the language to address libgcc, > >> libstdc++, etc. and libiberty, libbacktrace, etc.? > > > > I'll work on this a bit and share a draft. > > Hi David, > >

Re: [RFC] GCC Security policy

> On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote: > > On 2023-08-10 14:50, Siddhesh Poyarekar wrote: As a result, the only case for a potential security issue in all these cases is when it ends up generating vulnerable output for valid input source

Re: [RFC] GCC Security policy

On 2023-08-10 14:50, Siddhesh Poyarekar wrote:   As a result, the only case for a potential security issue in all   these cases is when it ends up generating vulnerable output for   valid input source code. I think this leaves open the interpretation "every wrong code bug is

Re: [RFC] GCC Security policy

> Am 10.08.2023 um 20:28 schrieb Richard Sandiford : > > Siddhesh Poyarekar writes: >> On 2023-08-08 10:30, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? >>> >>> I'll work on this a bit

Re: [RFC] GCC Security policy

On 2023-08-10 14:28, Richard Sandiford wrote: Siddhesh Poyarekar writes: On 2023-08-08 10:30, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit and share a draft. Hi David,

Re: [RFC] GCC Security policy

Siddhesh Poyarekar writes: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: >>> Do you have a suggestion for the language to address libgcc, >>> libstdc++, etc. and libiberty, libbacktrace, etc.? >> >> I'll work on this a bit and share a draft. > > Hi David, > > Here's what I came up with for

Re: [RFC] GCC Security policy

On 2023-08-09 14:17, David Edelsohn wrote: On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar > wrote: On 2023-08-08 10:30, Siddhesh Poyarekar wrote: >> Do you have a suggestion for the language to address libgcc, >> libstdc++, etc. and libiberty,

Re: [RFC] GCC Security policy

On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar wrote: > On 2023-08-08 10:30, Siddhesh Poyarekar wrote: > >> Do you have a suggestion for the language to address libgcc, > >> libstdc++, etc. and libiberty, libbacktrace, etc.? > > > > I'll work on this a bit and share a draft. > > Hi David, > >

Re: [RFC] GCC Security policy

On 2023-08-08 10:30, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit and share a draft. Hi David, Here's what I came up with for different parts of GCC, including the runtime

Re: [RFC] GCC Security policy

On 08/08/2023 20:39, Carlos O'Donell via Gcc-patches wrote: On 8/8/23 13:46, David Edelsohn wrote: I believe that upstream projects for components that are imported into GCC should be responsible for their security policy, including libgo, gofrontend, libsanitizer (other than local patches),

Re: [RFC] GCC Security policy

On Tue, 8 Aug 2023, David Malcolm via Gcc-patches wrote: > However, consider a situation in which someone attempted to, say, embed > libgccjit inside a web browser to generate machine code from > JavaScript, where the JavaScript is potentially controlled by an > attacker. I think we want to

Re: [RFC] GCC Security policy

On 8/8/23 13:46, David Edelsohn wrote: > I believe that upstream projects for components that are imported > into GCC should be responsible for their security policy, including > libgo, gofrontend, libsanitizer (other than local patches), zlib, > libtool, libphobos, libcody, libffi, eventually

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 1:36 PM Ian Lance Taylor wrote: > On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > > > BTW, I think we should perhaps differentiate between production ready > > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > > libssp) vs. e.g.

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 7:37 AM Jakub Jelinek wrote: > > BTW, I think we should perhaps differentiate between production ready > libraries (e.g. libgcc, libstdc++, libgomp, libatomic, libgfortran, > libquadmath, > libssp) vs. e.g. the sanitizer libraries which are meant for debugging and > I

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: > > On 2023-08-08 11:48, David Malcolm wrote: >> On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: >>> >>> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023

Re: [RFC] GCC Security policy

On 08/08/2023 15:40, Siddhesh Poyarekar wrote: On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit

Re: [RFC] GCC Security policy

On 2023-08-08 11:48, David Malcolm wrote: On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- patches wrote: There's probably external tools

Re: [RFC] GCC Security policy

On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: > > > > On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc- > > patches wrote: > > > There's probably external tools to do this, not

Re: [RFC] GCC Security policy

On 2023-08-08 10:37, Jakub Jelinek wrote: On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? I'll work on this a bit and share a draft. BTW, I think we should

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: > > Do you have a suggestion for the language to address libgcc, libstdc++, > > etc. and libiberty, libbacktrace, etc.? > > I'll work on this a bit and share a draft. BTW, I think we should perhaps differentiate between

Re: [RFC] GCC Security policy

On 2023-08-08 10:14, David Edelsohn wrote: On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar > wrote: On 2023-08-08 10:04, Richard Biener wrote: > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote: >> >> On Tue, Aug 8,

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar wrote: > On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > >> wrote: > >>> > >>> On Tue, Aug 08, 2023 at 02:52:57PM

Re: [RFC] GCC Security policy

On 2023-08-08 10:04, Richard Biener wrote: On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: There's probably external tools to do this,

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote: > > On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > > wrote: > > > There's probably external tools to do this, not sure if we should >

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: > > There's probably external tools to do this, not sure if we should replicate > > things in the driver for this. > > > > But sure, I think

Re: [RFC] GCC Security policy

> On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches > wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: >> There's probably external tools to do this, not sure if we should replicate >> things in the driver for this. >> >> But sure, I

Re: [RFC] GCC Security policy

Hello, On Tue, 8 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > What I'd really like to avoid is having all compiler bugs (primarily ICEs) > considered to be security bugs (e.g. DoS category), it would be terrible to > release every week a new compiler because of the "security" issues. >

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 3:01 PM Jakub Jelinek wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: > > There's probably external tools to do this, not sure if we should replicate > > things in the driver for this. > > > > But sure, I think the driver is the

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: > There's probably external tools to do this, not sure if we should replicate > things in the driver for this. > > But sure, I think the driver is the proper point to address any of such > issues - iff we want to

Re: [RFC] GCC Security policy

On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar wrote: > > On 2023-08-08 04:16, Richard Biener wrote: > > On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches > > wrote: > >> > >> FOSS Best Practices recommends that projects have an official Security > >> policy stated in a

Re: [RFC] GCC Security policy

On 2023-08-08 04:16, Richard Biener wrote: On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches wrote: FOSS Best Practices recommends that projects have an official Security policy stated in a SECURITY.md or SECURITY.txt file at the root of the repository. GLIBC and Binutils have

Re: [RFC] GCC Security policy

On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches wrote: > > FOSS Best Practices recommends that projects have an official Security > policy stated in a SECURITY.md or SECURITY.txt file at the root of the > repository. GLIBC and Binutils have added such documents. > > Appended is a