Creating a Secure, Sandboxed Docker Container

All of the information on how one would go about doing this can be found here: https://gvisor.dev/docs/user_guide/quick_start/docker/

Quick Breakdown on What This is

We're installing the gVisor here so that it can be run alongside any Docker container that is launched. There is significant reason for why this should be done (as it appears that Docker has been getting fried over the past year or so and we have the entire app portal running through the Docker at the time of writing ; therefore, we need to consider using this as a means of mitigating any potential vulnerabilities that could arise as a result of system calls being made outside of the sandbox + I'm not going to trust these mother fuckers up at Cloudron to be my last line of defense for this because I'm not entirely sure that they know what they're doing when it comes to ensuring security for Docker containers and we need to make sure that we are ultimately responsible for the security of our instance in a way that can't be covered by another 3rd-party configuration)

A guide on the actual architecture of this container can be found here = https://gvisor.dev/docs/architecture_guide/security/ (this is a meaningful read so that we can brief ourselves on how we're able to securitize against a number of potential vulnerabilities by using this tool)

Discussing Some of the Mitigations Afforded by the gVisor

On a personal PC level, we need to watch out for L1TF vulnerabilities (which come with older processors, hence the need for us to ensure that we're utilizing the latest generation ones; would prefer that it be AMD vs. Intel because it appears that they are more resistant to Spectre attacks overall, but this is still up for alteration contingent on what further information / research is uncovered to support / contradict this decision.

We will always go in the direction of empirical research.

Specifically, the project states:

"gVisor was created in order to provide additional defense against the exploitation of kernel bugs by untrusted userspace code."

Additionally enlightens us to the fact that bugs within the System API happen to be the most exploitable of all the bugs that are found within the kernel at a given point in time.

Mentions the incidence of hardware side channels, which we've already provided numerous mitigations for (on the home system; not entirely certain about what can be done for the 'away system' or the server setup itself -- this will come down, in part, to the hardware that the server is being ran on as long as we have it on a hosted server like Linode or something else)

Its a shame that the servers that we have running can't be ported over to OpenBSD, but that's also a fact of life created by OpenBSD since they're incompatible with virtualization (to a large extent; there is bhyve, but have never really explored that as something that can be viably used for anything meaningful -- perhaps this is a mistake of sorts, but there is nothing to my knowledge that this can be leveraged for ... perhaps this is worth looking into though /// will make sure to open a portion of the notes that are dedicated to address whether this should be the case or not)

First Step: Actually Installing Docker and Configure it Appropriately (takes two seconds max)

1. Download docker.io: sudo apt-get install docker.io whalebuilder subuser sen skopeo sen rootlesskit rkt docker-clean docker-compose docker-doc docker-registry

2. Once step one is complete, that's when a user must then run the following commands to ensure that Docker is setup and ready to go (added a few extra commands that are just useful to have in general): sudo systemctl enable docker then sudo systemctl start docker (one can add their user to the docker group, then 'cd' to the root [running cd /], and then run the command exec bash & that should refresh the terminal, allowing them to run commands via docker as a regular user instead of having to use 'sudo' all the time - cool)

Installing gVisor

This is actually the next step in the list that needs to be followed first (in order to get the runsc configuration setup)

Page can be found here: https://gvisor.dev/docs/user_guide/install/

Have to run this clunky ass code in order to make it all work:

(
  set -e
  URL=https://storage.googleapis.com/gvisor/releases/release/latest
  wget ${URL}/runsc ${URL}/runsc.sha512 \
    ${URL}/gvisor-containerd-shim ${URL}/gvisor-containerd-shim.sha512 \
    ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 \
    -c gvisor-containerd-shim.sha512 \
    -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc gvisor-containerd-shim containerd-shim-runsc-v1
  sudo mv runsc gvisor-containerd-shim containerd-shim-runsc-v1 /usr/local/bin
)

Assuming that the above step completes itself without any issue (again, this would be within a containerized container to begin with), then the next steps need to be run, which are:

/usr/local/bin/runsc install
sudo systemctl restart docker
docker run --rm --runtime=runsc hello-world

Don't need to necessarily run that last command, but that's simply to ensure that runsc has successfully been ran (this must be done after docker is installed)

Quick Note: Have to 'cd' into /usr/bin then check on the presence of runsc using 'fzf' (or just ls | grep runsc to see if its in a path where executables can be ran ; this is important, otherwise the other commands that need to be ran with 'runsc' won't be able to be ran from that point moving forward)

Believe That This is an Additional Step

So when I was initially running this in the container, I wasn't sure whether this step was an alternate means of downloading gVisor or supplementary to everything that had been done, but I just followed the step anyway because...why not ? (it didn't create any errors, conflicts or yield messages indicating re-installation of packages which = wasted time & resources).

Step One

Running the following:

sudo apt-get update && \
sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Then configuring the key for the signed archives and ofc adding the repo where gVisor is held at (so that we can pull it down via apt when we're finished)

curl -fsSL https://gvisor.dev/archive.key | sudo apt-key add -
sudo add-apt-repository "deb https://storage.googleapis.com/gvisor/releases release main"

Once all of the above has been completed, then 'runsc' can simply be installed via the packages (like a normal package at that point): sudo apt-get update && sudo apt-get install -y runsc

And boom, voila.

Configuring Docker to Use Runsc

1. Just need to run sudo runsc install first.

2. Then run sudo systemctl restart docker

Starting Up a Docker Container With the Runsc Runtime

1. We just need to specify it on the command line by adding in the '--runtime=runsc' directive amidst the usual commands that one would run with the docker container; for example: docker run --runtime=runsc --rm -it ubuntu /bin/bash

2. The command above should take us to a bash shell of an Ubuntu pull from their docker repos (read up later on Docker security as it pertains to tightening Docker to ensure that there are no "breaches" that occur as a result of pulling a bad image from a repository (there are fake / malware images out there that have been fucking people up ; additionally, we need to actually lockdown the Docker network to ensure that there are no compromises that occur through there either // following the CIS benchmark requisites should help -- again that will be touched on in a different piece)