As a regular developer I'm curious about looking at new projects. Let's say today I want to contribute to open source project in Python. This project is on GitHub and I a kind of confident in people behind this project. The only thing that bothers me is some mistake that could be made by chance by some developer which could potentially lead to unintended leakage of data from local machine. Like some mistake with paths / unintended copy from some random location / unintended upload / typo in pip dependencies which downloads some malicious library from pip. I'm a bit paranoid on these things especially when the project is new for me and I don't yet know code base and history.

What would be reasonable layer of protection there? I'm thinking about running project from docker sandbox under non-root user mounting only project source tree as a volume. Is it sufficient or what would be more reasonable?


If you're looking to run untrusted code on your system, then it does make sense (if possible) to sandbox the code, which reduces the impact of that code being malicious.

I'd say that running inside a Docker container as an unprivileged user is a good step. If all you're worried about is inadvertant leakage of information then Docker is a reasonable fit, as it provides the running code an isolated environment so any leakage would not affect the underlying system (unless you had mapped that directory in from the host OS via Docker run's -v switch)

  • @Rory, thanks for your answer. Well, approach I consider assumes that only one mount to docker container is done - project root itself. So, that all build / run steps in development cycle are executed from inside docker container. – tegoo Aug 19 '18 at 14:19
  • yep if you're just mounting the project root then any information leakage from within the container, wouldn't really provide useful information to an attacker as that's just the same information as would be in any other instance of that image. – Rоry McCune Aug 19 '18 at 14:34
  • Actually, I was thinking about security breakouts like we have seen last month with eslint (eslint.org/blog/2018/07/…). I think running build cycle from inside docker container would prevent leakage of .npmrc in those cases. So, I think using this approach is a good approach when we don't expect software to be dedicated on exploiting kernel bugs to break through container isolation. And actually I think that most of the issues would be much simpler like again with those eslint issue. – tegoo Aug 19 '18 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.