Hey, welcome back, another demonstration,
and a demonstration that we do really need to take a little bit seriously now.
We're going to give you a warning against using the Docker group.
Although it's the most obvious adding users into the Docker group,
it might not be the most secure mechanism.
The idea of this demonstration is to make you aware of what can be done,
what is possible by using Docker containers.
If you're not aware of it, it doesn't make your system any more secure,
so we want to make you aware of it so you can ensure that you're
running things in the correct and most secure manner.
Come on, let's just take a look at what we mean by all of this.
So here we are then back on our command line running as a standard user,
and if I try and even look at something like docker images,
I'm getting permission denied.
We do need to be run with elevated privileges,
but one way of elevating the privileges is by being
a member of the Docker group.
But let's just try running this again.
If I use sudo and!!, that will run docker images again.
But, before I run it, I've got another console window open,
let's change consoles.
Working on our second console, we can use sudo and tail,
to follow ‑f, don't show me any current lines,
‑n0,
and then the file that we want for this security
information is var/log/auth.log.
So this is just following the current auth.log file
without showing any current information.
If I go through then and execute the command,
we can see then that we're able to see our images,
but also returning to our log file,
we're able to see that the command was run by the vagrant user and we can see
the session being opened and closed for the root account.
So we're able to see that we ran the docker images command as the vagrant user,
and this is really important, traceability of who did what.
Now if I return back to my main console,
remember, we're saying that we could run the sudo command,
but we could also belong to the Docker group.
So if I use the gpasswd command, ‑a to add,
the current user, so I can use $USER to return my current username,
and we want to add them through to the Docker group,
and we can see there vagrant has been added to the group.
Id will show that I don't belong to the group,
but if I just exit out and then log back in again,
I will pick up the new group membership as soon as I log in again.
As I run the id command, we can see that I belong to the Docker group,
and as such, I can run docker images.
Now, in our second window,
we are still following the log file or we can go back and follow our log file,
run our docker images again, and go back and take a look in our log file,
and we won't have logged any information,
so it's clean and empty.
Now the problem is with this is that, well,
of course there are many things that I can do with Docker,
and the more I know about Docker, then I might try something like this,
docker run ‑ti or it, it doesn't matter the way you put it around.
That's going to give me an interactive terminal.
I don't need to name the container,
but it's often a good idea to name the container.
I'm just going to call it bad.
The bad part of this is I'm setting up ‑‑privileged.
This is going to give the container privileged
rights to the host operating system.
It's being run through the Docker service, which is running as root.
One really useful thing with containers is I can map volumes,
directories on our host system through to a directory in our container,
but here I'm mapping the root file system to a
directory called host in our container.
That directory doesn't exist.
It will be created in our containers file system.
We're going to be using the image ubuntu,
and then we specify the command that we want to run.
So we're going to be running the chroot command to change our root directory,
and the root directory on the container is going to be
pointing through to our host directory.
As I execute this, we've got to pull the image down, as it doesn't exist.
It will take a little bit longer, but it doesn't take too long, as you can see.
But I've got a root prompt, and if I run ls,
I can see the complete file system,
but this is actually the file system of my host operating system,
as we've mapped the volume through and chrooted.
We can prove this by adding a new user, so useradd ‑m bob,
so the home directory is going to be created as well,
and that's now the damage done, if you like.
If I exit out, I'm back on my host operating system,
and we can see there that I've got the bob user that has been created.
I've still been logging in my other terminal window,
and we can log the activity that the useradd command was run.
We created the bob command, but it doesn't show me who did it.
So we know something has happened,
but there's no traceability here of who actually created the user,
and of course I could have done something a little bit
worse than just creating a user.
But we can see the danger of not having the sudo system
logging through to our auth.log so we can trace who's run what with our Docker commands.