4 ms·

Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have cont

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.

unilynx 7y ago
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
mehrdadn 7y ago
> 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.
- dharmab 7y ago
  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.
  - anonymousDan 7y ago
    Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
    - willvarfar 7y ago
      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...?
      - eeZah7Ux 7y ago
        The attack surface of Docker is way more than a minimal, security-oriented container.
      - soraminazuki 7y ago
        > 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.
        deleted 7y ago
  - forty 7y ago
    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.
  - codedokode 7y ago
    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.
    - pdpi 7y ago
      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!
      - eeZah7Ux 7y ago
        On the contrary, docker increases the attack surface.
        pdpi 7y ago
        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.
  - merb 7y ago
    actually when it is a docker container running with gvisor, it is a real sandbox. without it, it definitv isn't. (https://gvisor.dev/ https://gvisor.dev/)
- thenewnewguy 7y ago
  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.
  - t0astbread 7y ago
    Are containers simpler to automate from a service provider's POV than, say KVM or qemu or Firecracker (or other VM tech)?
    - olalonde 7y ago
      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).
  - vsareto 7y ago
    We haven't lost the effort in securing bare metal systems. Those still work.
inimino 7y ago
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.
- londons_explore 7y ago
  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.
  - jagged-chisel 7y ago
    Why would your package manager require root to install packages? Can you not perform user-only installs?
    - londons_explore 7y ago
      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...
  - gmfawcett 7y ago
    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.
  - inimino 7y ago
    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.
eeZah7Ux 7y ago
And this is why we have Linux distributions and trust the maintainer process.

unilynx 7y ago

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

mehrdadn 7y ago

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

dharmab 7y ago
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.
- anonymousDan 7y ago
  Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
  - willvarfar 7y ago
    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...?
    - eeZah7Ux 7y ago
      The attack surface of Docker is way more than a minimal, security-oriented container.
    - soraminazuki 7y ago
      > 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.
      - deleted 7y ago
- forty 7y ago
  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.
- codedokode 7y ago
  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.
  - pdpi 7y ago
    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!
    - eeZah7Ux 7y ago
      On the contrary, docker increases the attack surface.
      - pdpi 7y ago
        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.
- merb 7y ago
  actually when it is a docker container running with gvisor, it is a real sandbox. without it, it definitv isn't. (https://gvisor.dev/ https://gvisor.dev/)
thenewnewguy 7y ago
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.
- t0astbread 7y ago
  Are containers simpler to automate from a service provider's POV than, say KVM or qemu or Firecracker (or other VM tech)?
  - olalonde 7y ago
    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).
- vsareto 7y ago
  We haven't lost the effort in securing bare metal systems. Those still work.

inimino 7y ago

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.

londons_explore 7y ago
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.
- jagged-chisel 7y ago
  Why would your package manager require root to install packages? Can you not perform user-only installs?
  - londons_explore 7y ago
    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...
- gmfawcett 7y ago
  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.
- inimino 7y ago
  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.

eeZah7Ux 7y ago

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