search

emk / rust-musl-builder

Docker images for compiling static Rust binaries using musl-libc and musl-gcc, with static versions of useful C libraries. Supports openssl and diesel crates.
Apache License 2.0
1.54k stars 193 forks source link

Consider avoiding sudo (especially, passwordless sudo) #59

Closed frol closed 5 years ago

frol commented 5 years ago

Passwordless sudo inside a container is almost the same as running the commands by root directly. What is the point of going through all the hassle of managing rust user if simple sudo -i will bring you to the root shell?

emk commented 5 years ago

Thank you for the question!

There's a couple of things going on here:

  1. You generally woudn't use rust-musl-builder as a base container for production. You should only use it to build, and then copy your binaries into a new, locked-down image using Docker multi-stage builds. Here's an example. So normally, this image should only be exposed to your own in-house source code and it should only be run in development or CI environments (such as on TravisCI).
  2. In many cases, users of rust-musl-builder will need to install more libraries using apt-get install -y. This requires sudo under Ubuntu, which is the reason I leave it installed in the default image.
  3. We create a rust user because it can be hard to get certain tools working as user root. Plus, it gives you the option of locking things down yourself.
  4. If you have a use case where you know you won't need sudo, I encourage you to remove it using apt-get remove sudo in your own Dockerfile.

So, basically this is a compromise between a number of different use cases. I want to provide some flexibility to users, but allow them to disable sudo once they've used it. And in any case, I strongly recommend using a different (smaller) base image for production.

frol commented 5 years ago
  1. I completely agree here, yet, I still believe that there is no much need in sudo in this case.
  2. There is no need in sudo for that, you can just do USER root before the RUN command.
  3. I completely support the use of a non-privileged user!
  4. That is true, but... :)
emk commented 5 years ago

There is no need in sudo for that, you can just do USER root before the RUN command.

Ah, this is handy! Had I known this, I would never have included sudo.

However, I am very reluctant to break other people's existing builds that rely on sudo without a clearer threat model to justify the breakage. But thank you for raising the issue!

frol commented 5 years ago

It is an unfortunate thing when it comes to security issues. I hope you reconsider your decision.