6 ms·

It does and you are root. You are evaluating inside a docker container. It's not a bulletproof method but it will stop a few. The instances evaluating your code

by masgui 9y ago

It does and you are root. You are evaluating inside a docker container. It's not a bulletproof method but it will stop a few. The instances evaluating your code is also on a network not accessible from the internet. I'm not an expert in security, if you have any advice on how we can improve our defence please tell us.

atemerev 9y ago
I am not a pentesting expert. My first reaction is to leave everything as is, as it is a very cool to play with root access to docker containers (I managed to reboot one, but a new one immediately appeared on page reload). My worst concern now would be network security. With root access, it is trivial to e.g. install spambots in all your containers (just checked, command execution works, and external network access is enabled). I think it is a good idea to at least disable networking. (Update: and use a minimal Docker image like Alpine Linux). Proof: [__REDACTED__]
- masgui 9y ago
  Yeah disabling networking was an idea. I prefer to leave it open so you can try http client/libraries that access the web. To limit spam, if it becomes an issue we could throttle the connection.
- opportune 9y ago
  I agree with this. What's to stop me from opening a bunch of the containers and using them to DDOS someone or to send out spam emails? I'm already playing around with system commands and they seem to be entirely unrestricted. Basically I can run any bash script, as is, with import sys.process._ "BASH_COMMAND" !! And I seem to be able to at least cause the containers to endlessly restart quite simply.
clhodapp 9y ago
The general rule is that you want as many layers of security as you can get away with without making things impractically inconvenient. In this case, the first step is probably not letting the user's code run as root in the container. Gaining container-root is going to be the first step in many, many exploits and by letting code just run that way, you are giving a potential attacker that step for free. Disclaimer: Absolutely not a security expert, just someone who is somewhat on the hook for security!
ronjouch 9y ago
Thumbs up for the honest upfront response! Maybe Jessica McKellar's "Building and Breaking a Python Sandbox" talk can bring some ideas. (But maybe not! It might be too Python-specific or too language-level whereas you want to remain at a higher level with just Docker) Video: https://www.youtube.com/watch?v=sL_syMmRkoU https://www.youtube.com/watch?v=sL_syMmRkoU Slides: https://speakerdeck.com/pycon2014/building-and-breaking-a-python-sandbox-by-jessica-mckellar https://speakerdeck.com/pycon2014/building-and-breaking-a-py...
j_s 9y ago
I recommend to at least wrap all the containers in a VM between the docker containers and your server-side orchestration code. SELinux also helps, from what I've read. https://news.ycombinator.com/item?id=14245428 https://news.ycombinator.com/item?id=14245428
wsargent 9y ago
I put together a list of security tips: https://github.com/wsargent/docker-cheat-sheet#security-tips https://github.com/wsargent/docker-cheat-sheet#security-tips Probably the biggest one is to use Virtualbox or another virtual machine so that Docker isn't your only line of defence.
- tutanchamun 9y ago
  > I put together a list of security tips: [...] and 63 contributors. ;p
  - wsargent 9y ago
    Check the blame log. That section's all me.
    - tutanchamun 9y ago
      https://github.com/wsargent/docker-cheat-sheet/pull/91 https://github.com/wsargent/docker-cheat-sheet/pull/91 Please don't misunderstand this. I know from reading your postings on /r/scala that you are a humble person. Originally I actually didn't even knew if there was a contributor to the security section besides you and only wanted to tease. :D
      - wsargent 9y ago
        Fair enough -- I was actually thinking of https://github.com/wsargent/docker-cheat-sheet/blame/master/README.md#L484 https://github.com/wsargent/docker-cheat-sheet/blame/master/... but that's a fair counterexample.
eranation 9y ago
Congrats Guillaume! How much of ScalaKata code is in there? Sorry if I missed it in the post, but is Scastie open source? I'd love to finally fix scalatutorials.com :) p.s. did you guys consider using a "serverless" architecture to isolate runners instead of docker? Also, are you running it with java -Djava.security.manager? If not then why?
- masgui 9y ago
  The security manager can be disabled using reflection. If you don't allow you loose some libraries like Akka. The main thing that is missing from ScalaKata is autocompletion and it will be implemented in the summer during the GSOC. AWS lambda could be worth investigating. We don't expose an API for evaluating but others have expressed this need. Can you create an issue on GitHub for that?
  - eranation 9y ago
    Gladly, sorry for the silly question, but on which repo? Scala Lang main website? Scalakata?
    - masgui 9y ago
      This is the main repo: https://github.com/scalacenter/scastie https://github.com/scalacenter/scastie. It's not at silly question at all.
  - wsargent 9y ago
    You can use an agent to disable the security manager disabling. :-) https://tersesystems.com/2016/01/19/redefining-java-dot-lang-dot-system/ https://tersesystems.com/2016/01/19/redefining-java-dot-lang...

by masgui 9y ago

atemerev 9y ago

I am not a pentesting expert. My first reaction is to leave everything as is, as it is a very cool to play with root access to docker containers (I managed to reboot one, but a new one immediately appeared on page reload). My worst concern now would be network security. With root access, it is trivial to e.g. install spambots in all your containers (just checked, command execution works, and external network access is enabled). I think it is a good idea to at least disable networking. (Update: and use a minimal Docker image like Alpine Linux). Proof: [__REDACTED__]

masgui 9y ago
Yeah disabling networking was an idea. I prefer to leave it open so you can try http client/libraries that access the web. To limit spam, if it becomes an issue we could throttle the connection.
opportune 9y ago
I agree with this. What's to stop me from opening a bunch of the containers and using them to DDOS someone or to send out spam emails? I'm already playing around with system commands and they seem to be entirely unrestricted. Basically I can run any bash script, as is, with import sys.process._ "BASH_COMMAND" !! And I seem to be able to at least cause the containers to endlessly restart quite simply.

clhodapp 9y ago

The general rule is that you want as many layers of security as you can get away with without making things impractically inconvenient. In this case, the first step is probably not letting the user's code run as root in the container. Gaining container-root is going to be the first step in many, many exploits and by letting code just run that way, you are giving a potential attacker that step for free. Disclaimer: Absolutely not a security expert, just someone who is somewhat on the hook for security!

ronjouch 9y ago

Thumbs up for the honest upfront response! Maybe Jessica McKellar's "Building and Breaking a Python Sandbox" talk can bring some ideas. (But maybe not! It might be too Python-specific or too language-level whereas you want to remain at a higher level with just Docker) Video: https://www.youtube.com/watch?v=sL_syMmRkoU https://www.youtube.com/watch?v=sL_syMmRkoU Slides: https://speakerdeck.com/pycon2014/building-and-breaking-a-python-sandbox-by-jessica-mckellar https://speakerdeck.com/pycon2014/building-and-breaking-a-py...

j_s 9y ago

I recommend to at least wrap all the containers in a VM between the docker containers and your server-side orchestration code. SELinux also helps, from what I've read. https://news.ycombinator.com/item?id=14245428 https://news.ycombinator.com/item?id=14245428

wsargent 9y ago

I put together a list of security tips: https://github.com/wsargent/docker-cheat-sheet#security-tips https://github.com/wsargent/docker-cheat-sheet#security-tips Probably the biggest one is to use Virtualbox or another virtual machine so that Docker isn't your only line of defence.

tutanchamun 9y ago
> I put together a list of security tips: [...] and 63 contributors. ;p
- wsargent 9y ago
  Check the blame log. That section's all me.
  - tutanchamun 9y ago
    https://github.com/wsargent/docker-cheat-sheet/pull/91 https://github.com/wsargent/docker-cheat-sheet/pull/91 Please don't misunderstand this. I know from reading your postings on /r/scala that you are a humble person. Originally I actually didn't even knew if there was a contributor to the security section besides you and only wanted to tease. :D
    - wsargent 9y ago
      Fair enough -- I was actually thinking of https://github.com/wsargent/docker-cheat-sheet/blame/master/README.md#L484 https://github.com/wsargent/docker-cheat-sheet/blame/master/... but that's a fair counterexample.

eranation 9y ago

Congrats Guillaume! How much of ScalaKata code is in there? Sorry if I missed it in the post, but is Scastie open source? I'd love to finally fix scalatutorials.com :) p.s. did you guys consider using a "serverless" architecture to isolate runners instead of docker? Also, are you running it with java -Djava.security.manager? If not then why?

masgui 9y ago
The security manager can be disabled using reflection. If you don't allow you loose some libraries like Akka. The main thing that is missing from ScalaKata is autocompletion and it will be implemented in the summer during the GSOC. AWS lambda could be worth investigating. We don't expose an API for evaluating but others have expressed this need. Can you create an issue on GitHub for that?
- eranation 9y ago
  Gladly, sorry for the silly question, but on which repo? Scala Lang main website? Scalakata?
  - masgui 9y ago
    This is the main repo: https://github.com/scalacenter/scastie https://github.com/scalacenter/scastie. It's not at silly question at all.
- wsargent 9y ago
  You can use an agent to disable the security manager disabling. :-) https://tersesystems.com/2016/01/19/redefining-java-dot-lang-dot-system/ https://tersesystems.com/2016/01/19/redefining-java-dot-lang...