Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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 headers directory) into the sandbox before 
invocation.  The output file could perhaps be enforced as having to be a 
new one, i.e. fail if the target is already found.

> I'm not sure a generic utility can achieve this unless the outputs need to be
> retrieved from somewhere else (not "usual" place when invoking un-sandboxed).
> 
> Even the driver doesn't necessarily know all files read/written.
> 
> So I suppose better defining of the actual goal is in order.
> 
>> gcc -sandboxed -O2 -c t.ii -fdump-tree-all
> 
> what should this do?  IMO invoked tools (gas, cc1plus) should be restricted
> to access the input files.  Ideally the dumps would appear where they
> appear when not sandboxed but clearly overwriting existing files would be
> problematic, writing new files not so much, but only to the standard (or
> specified) auxiliary output file paths.

Couldn't we get away with not having to handle dump files?  They don't 
seem to be sensitive targets.

Thanks,
Sid