Challenges faced with Runc

Introduction and motivation

I started working on Runc since past 2 weeks and it has indeed helped me articulate the infrastructure I wanted to have. The use cases for Runc stands out as it helps to create a docker container with ease. A docker container can help you add more security to your app or solution. As an attacker I will always look for secure system related information access like /etc/passwd. Docker solution can provide a jail environment which will not allow the attacker to get access of anything outside jail scope. The use case is potent enough for any application scope.

Creating a docker container is not at all a rocket science, and to add a cherry to the cake, now we have runc. Runc is a wrapper around docker which in turn spawns up a container without you installing docker on your machine. Let me give a brief about the environment setup before diving into the challenges I faced during this exploration.

Pre-requisites

I verified all my experiments in CentOS so will be discussing the same

1. Make sure Kernel OS is 2.6.32-642.6.2 or higher 

2. Install Go from here
https://golang.org/doc/install
3. Build Runc by following documentation at here
https://github.com/opencontainers/runc
4. Make sure you have gcc if not execute the following
sudo yum install gcc gcc-c++
5. Runc will get installed in /usr/local/sbin , make sure this is in your path

 Troubleshoot 

I am not going to talk about the execution aspect of Runc because the intention of this blog is to save time for others who might get stuck in situations I have faced

Troubleshoot #1

Issue Link : https://github.com/opencontainers/runc/issues/1270

I started getting this broken pipe error pretty early in the stage. Things began to get worse when I was getting solution related to docker and not related to runc. Runc is pretty new player, so we don't see enough discussion threads around it. I was struggling to get response from Runc forum too.

During my exploration I happen to hit this thread where people were discussing about the related services. This led me to search for cgroup services.

Here cgroup means control groups, you can define max min caps for cpu processes, memory utilization etc in these cgroups. For me this service was turned off. I need to explicitly execute
Service cgconfig start
to make this service start which solved the issue.

Troubleshoot #2

In config.json you can have mounted section for cgroup

{
                        "destination": "/sys/fs/cgroup",
                        "type": "cgroup",
                        "source": "cgroup",
                        "options": [
                                "nosuid",
                                "noexec",
                                "nodev",
                                "relatime",
                                "ro"
                        ]
 }

This section means that there will be a mounted path created on container which is noexecutable and read only path in the target container

The issue we are talking here is similar to broken pipe issue which we discussed in troubleshoot #1, whose solution is also the same. Because of service unavailable you might see the broken pipe issue. Service cgconfig start , solves the issue.

Troubleshoot #3

Issue Link: https://github.com/opencontainers/runc/issues/1299

I should mention the solution of this issue is a sloppy hack. Runc is currently built with glibc 2.14. Another blocker arose when I figured out that my machine had glibc.2.12 and till date I have not found any solution where I can build runc using libc 2.12

Still I am trying to find a permanent solution to this but to unblock you here is the sloppy hack I mentioned earlier

  sed s#"2.14"#"2.12"#gi /path/to/runc > runc_new

This will rename all 2.14 versions to 2.12, and will help you to get unblocked.

Troubleshoot #4

When you are building runc you get couple of BuildTags with which you can build it 

Build TagFeatureDependency
seccompSyscall filteringlibseccomp
selinuxselinux process and mount labeling
apparmorapparmor profile supportlibapparmor
ambientambient capability supportkernel 4.3
 Quoting from https://github.com/opencontainers/runc/blob/master/README.md

Each Build Tag has its importance. Initially I was having selinux from my tutorial while building runc
make BUILDTAGS='selinux'
I figured out this was an issue for my runc as SeLinux was not a compiler support in my case. In such situation I will suggest you include BUILDTAGS with empty params like
make BUILDTAGS=''

Conclusion

The primary intent to capture these findings in a blog is not only for future reference but also is an approach of validating my observation. If you feel I have captured something wrong please do mention it.

I will continue capturing the issues with associated learnings. Hope this helps.
 
 

Comments

Popular posts from this blog

Firebase authentication with Ionic creator

Big Data - SWOT Analysis

LINKEDIN api call using NODE.JS OAUTH module