Re: [RFC] GCC Security policy

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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.

There are two distinct sets of ideas to explore, one is privilege 
management and the other sandboxing.

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 because it would need a user to drop privileges 
to and then there would be the question of how to manage file access to 
read the compiler input and write out the compiler output.  If there's 
no such user, gcc could refuse to run as root by default.  I wonder 
though if from a security posture perspective it makes sense to simply 
discourage running as root all the time and not bother trying to make it 
work with dropped privileges and all that.  Of course it would mean that 
this would be less of a "project"; it'll be a simple enough patch to 
refuse to run until --allow-root is specified.

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 non-root.

Sandboxing will have similar requirements, i.e. map in input files and 
an output file handle upfront and then unshare() into a sandbox to do 
the actual compilation.  This will make sure that at least the 
processing of inputs does not affect the system on which the compilation 
is being run.

Sid