Hacker News Reader

Comment by nneonneo | Hacker News Reader

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.

View on HN

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

Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?

The attack surface of a container is massive.

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...?

The attack surface of Docker is way more than a minimal, security-oriented container.

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

Interesting, do you have a link to the paper?

I think I you run it without --privileged and userns enabled it's not that bad, since at least the processes run with an unprivileged user.

Docker was not made for security, and this is explicitly documented in its manual.

Also, you don't need VM, just playing with namespaces, chroots and syscall filters should be enough. VMs are very ineffective and complicated.

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!

On the contrary, docker increases the attack surface.

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.

actually when it is a docker container running with gvisor, it is a real sandbox. without it, it definitv isn't. (https://gvisor.dev/)

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.

Are containers simpler to automate from a service provider's POV than, say KVM or qemu or Firecracker (or other VM tech)?

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).

We haven't lost the effort in securing bare metal systems. Those still work.

In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.

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.

Why would your package manager require root to install packages? Can you not perform user-only installs?

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

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.

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.

Well, if he saw an actual hash... there’s generally no reason a docker container should have any password hashes in /etc/shadow.

Of course how a specific container is built is anyone’s guess

And this is why we have Linux distributions and trust the maintainer process.

Reply on news.ycombinator.com