This is a play proposal for a new wrapper around go build that would build your binary but
wrap it in code that would prepare isolation around your binary on run.
A concept of this is in https://github.com/jfrazelle/binctr, in that it takes a docker image and embeds the contents into a final binary so you have a self-contained binary.
The binctr example is unnessesarily heavy for go binaries because all you need is a completely static
binary.
Also by doing this in the build step we can do some heavy lifting for you and create more secure isolation.
As an example of this, we could parse your code and find all the syscall's that would be called if everyline of your code is executed. Then on run we can provide a seccomp whitelist based off that data and apply it to the binary process.
App developers know their code the best so the isolation settings should be up to them and can be provided by a config file on build. Which namespaces the isolation should use and resource constraints could all be customizable.
Containers are cool, but it's all just code at the end of the day, go binaries could very easily sandbox themselves without the need for a daemon or seperate binary to do the work.
This is super interesting, I'm curious to see what you come up with. Just knowing what syscalls an application and its dependencies are actually using would be super useful for evaluating OSS projects and bringing more knowledge to developers about how their OS works and what pieces of it they're using and which kernel tunables to then go and investigate based on their app performance...
FWIW, we currently do a two phase build in our docker golang build pipeline, where the first stage compiles in a 'build' container and the second stage generates the deployable container
FROM scratch, which has always felt like a bit of overly complex shenanigans...