Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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 conclusion. What is the problem with
> passing untrusted code to a sandboxed compiler?
> 
>> Right, that's what we're essentially trying to convey in the security policy
>> text.  It doesn't go into mechanisms for securing execution (because that's
>> really beyond the scope of the *project's* policy IMO) but it states
>> unambiguously that input to the compiler must be trusted:
>>
>> """
>>                                            ... It is necessary that
>>      all source code inputs to the compiler are trusted, since it is
>>      impossible for the driver to validate input source code beyond
>>      conformance to a programming language standard...
>> """
> 
> I see two issues with this. First, it reads as if people wishing to build
> not-entirely-trusted sources need to seek some other compiler, as somehow
> we seem to imply that sandboxing GCC is out of the question.
> 
> Second, I take issue with the last part of the quoted text (language
> conformance): verifying standards conformance is also impossible
> (consider UB that manifests only during linking or dynamic loading)
> so GCC is only doing that on a best-effort basis with no guarantees.

Does this as the first paragraph address your concerns:

The compiler driver processes source code, invokes other programs such 
as the assembler and linker and generates the output result, which may 
be assembly code or machine code.  It is necessary that all source code 
inputs to the compiler are trusted, since it is impossible for the 
driver to validate input source code for safety.  For untrusted code 
should compilation should be done inside a sandboxed environment to 
ensure that it does not compromise the development environment.  Note 
that this still does not guarantee safety of the produced output 
programs and that such programs should still either be analyzed 
thoroughly for safety or run only inside a sandbox or an isolated system 
to avoid compromising the execution environment.

Thanks,
Sid