Are Containers on Mainframes Safe?
Let’s just start with some basics: What is a container?
A container is a standard unit of software that packages up code and all of its dependencies, so the application runs quickly and reliably in different computing environments. In effect, this container can be taken from one computing platform to another, and it will still run the same way.
Container Strategies and Tools
You may well be familiar with Docker, which is, perhaps, the best-known way to produce these containers. So, why do people use containers rather than just run the application in the usual way? The answer is that containers isolate the software from the surrounding environment and ensure that it works uniformly on different infrastructure.
You might also have heard of Kubernetes (or k8s), which is an open-source container-orchestration system for automating application deployment, scaling and management. It works with a range of container tools, including Docker, and many cloud services offer a Kubernetes-based platform or infrastructure as a service (PaaS or IaaS) on which Kubernetes can be deployed as a platform-providing service.
On a mainframe, you can use z/OS Container Extensions (zCX), which provides a way to run Linux capabilities on z/OS. In fact, it runs in a started task and contains both a full Linux system (Ubuntu) and Docker. It’s set up to expose Docker-based functionality, and the benefit is that z/OS can run Linux code that has an affinity for z/OS data or applications. IBM’s z/OS Management Facility (z/OSMF) interface is used to provision, deprovision and otherwise maintain zCX instances.
Users can access the appliance through a container that’s built and deployed by default from IBM’s secure shell command line interface (SSH CLI) container, which communicates to the Linux host using the Docker daemon.
Container Security
Everyone assumed that what ran in a mainframe container stayed in a mainframe container until Ian Coldwater, a leading expert on containers and container security, and Chad Rikansrud, a leading expert on mainframes and mainframe security, gave a presentation at DEF CON 29.
The question that Coldwater and Rikansrud asked themselves was, what if a user could gain root access to or modify zCX itself? And that’s what they set out to do using their combinations of expertise. In an interview with SHARE they said that they thought zCX would be difficult to secure properly, especially in the initial release.
And, sure enough, once they started looking for them, they found several vulnerabilities, including some that stemmed from incorrect assumptions on how to secure Docker, outdated versions of software, and permissions on z/OS that were too relaxed.
Coldwater found that the initial user in the SSH CLI container was a member of the Docker group, which can lead to escaping the container and gaining root access to the host in certain configurations. zCX had one of these configurations in place. It seemed that the SSH CLI container communicated directly with an exposed Docker daemon on the Linux host, allowing users in the Docker group (such as the one in the CLI container) to create and manipulate containers running on the host.
Not surprisingly, there’s now a Docker authorization plugin from IBM called zcxauthplugin, However, the plugin doesn’t protect the Docker Engine API—an HTTP-based API that comes with Docker, which can be used to issue a number of commands through the Docker command line tool. Using the Engine API to bypass the zcxauthplugin, Coldwater could send commands to create a container that allowed access to host resources. This took him out of the container and gave him access to the host.
Rikansrud found that, by default, the UNIX System Services files used to provision and build the zCX instance lacked basic file-system security. He commented that this would allow any malicious user to backdoor these files such that any container created from them would be compromised from the start.
Coldwater and Rikansrud thought that any organizations implementing zCX would know how to secure the z/OS address space, users, USS files and directories, and zOSMF configurations. They also warned companies not to cut corners because they would become insecure.
Containers and Cloud
There’s also been growth in the use of containers on cloud platforms (using technology such as Red Hat OpenShift), as well as on mainframes. Containers offer a number of advantages to users, such as using fewer system resources than running virtual machines. They also allow speedier application development and implementation. And, if you’re moving them to a different platform (including the cloud), they provide more consistent operation.
They also offer improve security because they isolate applications from the host system and from each other. I assume that the security vulnerabilities identified by Coldwater and Rikansrud have been patched and bad actors won’t be able to follow their example and breakout of a container and cause a mainframe breach.
It just goes to show that we all need to be vigilant, where security is concerned, at all times.