Define a Dockerfile for local development purposes

[rayanht]

#18

[rayanht]

An alternative to this Dockerfile could simply run the quick_start.sh script but my motivation is that this is a lot more clearer and maintainable.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[rayanht]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[JonZeolla]

This cannot work as currently documented because 127.0.0.1 in the container does not refer to 127.0.0.1 on the host. Consider setting up a docker network, or something with compose. The docker network approach would be something like:

docker network create example
docker run --network example --name unauthenticated-jupyter-notebook -p 8888:8888 -d jupyter/base-notebook start-notebook.sh --NotebookApp.token=''
docker run --network example tsunami java -cp "/usr/tsunami/tsunami-main-0.0.2-SNAPSHOT-cli.jar:/usr/tsunami/plugins/*" -Dtsunami-config.location=/usr/tsunami/tsunami.yaml com.google.tsunami.main.cli.TsunamiCli --hostname-target=unauthenticated-jupyter-notebook

Minor other feedback:

• Suggest updating the TARGET_IP approach to differentiate between v4 and v6 and adding support for --hostname-target (see this)
• Consider using a combination of ENTRYPOINT and CMD to allow arguments to be overridden to the defined base command at docker run. Something like the following would allow a simplification of the docker network example's last command to docker run --network example tsunami --hostname-target=unauthenticated-jupyter-notebook.

  ENTRYPOINT ["java", "-cp", "/usr/tsunami/tsunami-main-0.0.2-SNAPSHOT-cli.jar:/usr/tsunami/plugins/*", "-Dtsunami-config.location=/usr/tsunami/tsunami.yam", "com.google.tsunami.main.cli.TsunamiCli"]
  CMD -- --ip-v4-target=$TARGET_IP
  

Note: I'm not affiliated with this project or Google, just giving some feedback...

[rayanht]

@JonZeolla Thanks for the suggestions! Re: the docker network, how about simply running the Tsunami image with --network="host" ? This would allow to scan for vulnerabilities in applications that aren't necessarily docker images themselves.

[vdjagilev]

Have a little side note for this one.

I am not sure how gradle defines a version for any particular .jar file it creates. But in this case tsunami-main-0.0.2-SNAPSHOT-cli.jar is hardcoded into Dockerfile. I think it would be good if there is no need to change Dockerfile each time when jar file name is different.

Maybe it's possible to do something like this JARFILE=$(find ...), I think this would be good example https://github.com/google/tsunami-security-scanner/blob/master/quick_start.sh#L57

[rayanht]

@vdjagilev I considered it but I wasn't aware of the basename command. Will definitely amend, thank you for the heads up!

[rayanht]

A bit of an update on this, there is no way to persist variables between RUN commands in Docker and I can't seem to get command interpolation to behave nicely inside the ENTRYPOINT.

To be honest, I don't really see the point in specifying the version number in the filename of the generated jar. Could we perhaps drop it and have a standard filename?

[JonZeolla]

How I've solved this in the past is to use a build arg (ARG), and then use something like a Makefile or wrapper shell script that grabs the version from the project and passes it into the docker build via an arg.

While its a completely different project and context, here is a concrete example:

1. Grab the version
2. Provide it as a build arg
3. Use it at build time

[rayanht]

@JonZeolla Yep that would definitely work, it's just that I would've preferred a fully self-contained Docker image that the end user could simply docker run

[JonZeolla]

What about just finding the jar at build time and rename it to a standard name like tsunami-main-cli.jar and use that in the ENTRYPOINT?

[rayanht]

@JonZeolla ...it's so obvious that I didn't think about it 😅

[vdjagilev]

Maybe it's better to leave old documentation and divide installation approaches into 2 topics (with docker and without docker)? Use case: Running docker in VM with Kali Linux can be memory-expensive