Make Popular Paths Popular

Nowadays, untrusted or buggy programs are everywhere, from plugins running in your web browser, to a third-party Python library running on your local machine. As awareness of the scope of this problem grows, many people are turning to containers to protect their system from the security breaches these untrusted programs can cause. Containers have become an attractive solution because, as the name implies, they can provide isolation, and “contain” programs run inside of them. With emerging containerization tools, such as Kubernetes and Docker, providing practical solutions for deploying and running programs, more and more people are choosing containers.

However, as use of the technology has expanded, it has become clear that “containers” do not really contain all that well. Ultimately, they have to rely on the underlying host kernel to perform core functionalities, such as file system operations, network, etc. With so many security vulnerabilities inside the host kernel, giving it access to risky code could create a huge problem.

As containers cannot function without access to the host kernel, then the question becomes can we identify where the bugs may be located and prevent access to those areas? Almost two years ago, as part of the Lind project, we developed and tested a metric that could predict where bugs are likely to be located in the Linux kernel. The central idea is that the “popular paths”, which refer to lines of code frequently executed by popular user programs, contain fewer bugs and so, if access could be limited to these paths, the chance of triggering bugs would be greatly reduced.

In the work referenced above, we showed it was possible to build a virtual machine that functioned with only limited access to the kernel. After obtaining the popular paths for an Ubuntu system by running the top 50 packages from the Ubuntu popularity contest, we were able to demonstrate that these paths in the Linux kernel tend to contain fewer security bugs. Thus, by restricting access to risky “unpopular paths,” bugs could be effectively prevented from being triggered in the kernel. We defined a standard procedure, which we called “Lock-in-Pop,” that anyone could follow to obtain the “popular paths” for a favorite virtual machine.

So can we now apply this metric and the notion of restricting path access to containers and other types of virtualization systems? The next stage of
popular paths research suggests we can. Currently, we are using the metric to develop a “safe mode” of the Linux kernel, which can be used to run the LinuxKit container. In our preliminary experiment, we ran 14 popular Docker containers from Docker Hub with LinuxKit, and used the Gcov kernel profiling tool to capture the kernel trace. We were able to obtain the “popular paths” for LinuxKit, and then inserted the kernel panic() system call at the beginning of the “unpopular paths” to prevent access to this risky code in the host kernel. We modified more than twenty three thousand functions in the Linux kernel, which accounts for about one third of its total number of functions. And we verified that the LinuxKit container can still perform required functions with our modified host Linux kernel. Though we are still running tests at this time, we have reason to believe that with this method of trimming the kernel, the issue of negotiating access to untrusted code can be addressed.

For software developers and users who run programs in containers, staying on the popular paths could significantly enhance the security of the host kernel. With this in mind, we actively encourage researchers and developers to try out the metric in container measurements and security evaluations. If enough researchers can help us “make popular paths popular,” and are willing to share their results, we believe the insights gained could lead to more secure virtualization systems.