Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have contained memory corruption bugs or similar issues that could be leveraged to gain code execution. Many services that compile untrusted code will run the resulting binaries too, which definitely requires a sandbox or disposable VM - at which point you may as well throw your whole compiler in the sandbox/VM too.
I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service.
> I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service.
My understanding is that Docker isn't something you use if you really want security.
You're being downvoted but you're right- Docker really isn't a good choice for running untrusted and potentially hostile code, since a container breakout zero-day pretty much immediately compromises the host OS. (Even with user namespace remapping a breakout still gives enough access to get up to shenanigans.)
At the minimum a disposable VM using something like KVM/QEMU/Firecracker would be a start. That way you have kernel isolation down to the hardware which is much less likely to be exploitable.
The attack surface of a hypervisor is tiny, in comparison.
There was 'interesting' research out of IBM a couple of years ago where they claimed they found that containers with good seccomp profiles etc were 'as secure as' a VM. Well, nobody goes around believing that.
I recall once asking Joanna Rutkowska this same question, I think just days after she had outlined some pretty glaring security issues in the Xen hypervisor. She pointed out that if we were finding (and fixing) security issues in the 2K (or 20K, or however big the trusted-computing-base of Xen is, I forget) then imagine the number of issues laying unfound in your modern kernel...?
> There was 'interesting' research out of IBM a couple of years ago where they claimed they found that containers with good seccomp profiles etc were 'as secure as' a VM. Well, nobody goes around believing that.
You're leaving out a key detail of that research. They never said that tuning seccomp profiles to secure existing containerized apps is practical or effective. In fact, quite the opposite. IIRC, what they actually did is to create a hypervisor-like narrow interface on top of containers by restricting the available system calls to closely resemble KVM's hypercall interface. This design allowed the authors to reduce the size of the trusted computing base while avoiding overheads associated with VMs, though it would also limit the ability to run unmodified Linux binaries. Overall, I found it to be an interesting alternative to containers or VMs.
Funny you say the docker is not for security (it’s there in the manual) but then suggest chroot of all things — that is just as well documented as not being meant for security!
The point is that neither tool has a security focus, any security characteristics they might have are incidental and not at all guaranteed, and so neither should be used for that purpose.
This is true, but containers are so much better than nothing and relatively simple to use, so if someone isn't going to put in the effort for a more secure solution I'd rather they use Docker than nothing.
Yes, Docker largely became popular because of its user friendliness. Running a containerized compile job can be quickly done in a single command (e.g. docker run --rm -v "$(pwd):/src" -t ownyourbits/mmake).
Why not? There's a good chance the user will be needing to install extra packages or libraries, or run custom makefile steps that require extra permissions the system designer couldn't anticipate.
Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.
Running a compiler as root in general is not recommended. It's the principle of least privilege. Running without unnecessary privileges is a good idea for the same reason running in a sandbox is a good idea.
Custom makefile steps that require running the compiler as root? More likely they need to run `chown` or `chmod` or something else as root -- i.e., something that has a far smaller attack surface.
Sure some can, but if you're making a compiler-as-a-service, you want it to be compatible with as many as possible. I suspect being root maximizes compatibility. Hardcoded "/usr/bin" paths are just the start...
I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service.