- So I made a curl call,
creating a new container that mounted the host path
as a read/write bind map via engine syntax
and hey, it works.
So, I knew that making calls could work
and that bindings was an option they missed. Sweet.
But when I tried chroot-ing out into the whole system
it didn't quite work the way that I wanted it to,
because they had enabled user namespace remapping.
What this means for my purposes is that
once I was out of that namespace,
even though it said I was root,
I couldn't really do anything meaningful in that namespace.
And they had locked down the sudoers file real hard,
which was throwing weird permissions errors
that I haven't seen before.
So that was kind of odd, but okay,
maybe this one wasn't going to work, but at this point,
I knew I was getting somewhere.
I'm gonna take a second here to explain
user namespace remapping, because it's important.
Linux namespaces provide isolation for running processes.
They limit their access to system resources
without the running process being aware of the limitations.
You don't want to run your containers as a root user,
generally, it is not a secure thing to do.
But sometimes for various system reasons,
you get a container in which something has to run as root.
So, for those containers whose processes
have to run as the root user within the container,
you can remap this user via user namespace remapping
to a less-privileged user on the Docker host.
The mapped user is assigned a range of UIDs,
which function within the namespace as normal UIDs
from 0 to 65536, but they have no privileges
on those machine itself. This was why,
even though I was theoretically running as UID 0,
I couldn't really get anywhere.
So, knowing that the API calls could work to the engine API,
but that user namespace remapping was kind of cramping
my style, I figured I'd try something else.
I tried a user namespace host option through the API
because setting user namespace to host
breaks user namespace re-mapping.
This option was blocked by the plugin
when I had tried it before in a Docker run command,
but via the API it worked.
And this time when I got in,
I had full root access to all of these resources.
Wow.
This system really needed more defensive depth.
It appeared to have been built upon the assumption
that no one could ever become root on the host,
like they really believed their own propaganda.
So, nothing was really locked down on the backend
by that point. Once you were in, and once you were root,
you could really do whatever.
And it was kind of fun, actually.
I haven't really had that much fun running around
an environment since like early Kubernetes,
which was similarly locked down.
And I hadn't gotten to do that.
So in a, in a while, since Kubernetes improved,
so that was fun for me. Anyway.
The first thing I did once I had access to
the host file system was look inside the root folder.
Because you know, why not? And in the root folder,
there was another folder called root keys.
Well, that sounded great.
Obviously there's gonna be something interesting
in root keys. So I took a look in there,
and I found a private key called,
IBM encapsulation private pem.
Didn't quite know what that was,
but I think you probably, you did.
So I went and handed it in Chad,
figuring it might be useful.
Chad, then took the key, reversed engineered
the COBOL or something.
And then we had a system to look at.