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, although I'll need someone to > assist with actual approvals.
I'm sure that we could manage that. The project does not look like it would be a huge one. > > 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. Yeah, this would not be enough for a GSoC project, not even for their new small project category. Additionally, I think that many, if not all, Linux distributions that build binary packages do it in a VM/container/chroot where they do it simply under root because the whole environment is there just for the build. So this would complicate lives for an important set of our users. > > 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. Right. As we often just download some (sometimes large) pre-processed source from Bugzilla and then happily run GCC on it on our computers, this feature might be actually useful for us (still, we'd probably need a more concrete description of what we want, would e.g. using "-wrapper gdb,--args" work in such a sandbox?). I agree that for some even semi-complex builds, a more general sandboxing solution is probably better. Martin
