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
