[Docker, Inc.'s package] Does runc included in containerd v1.2.0 statically linked to a libssl?

[diabloneo]

In some of our environments, we deployed docker v19 version:

[root@node sbin]# docker version
Client: Docker Engine - Community
 Version:           19.03.12
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        48a66213fe
 Built:             Mon Jun 22 15:46:54 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:45:28 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.0
  GitCommit:        c4446665cb9c30056f4998ed953e6d4ff22c7c39
 runc:
  Version:          1.0.0-rc5
  GitCommit:        4fc53a81fb7c994640722ac585fa9ca548971871
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Recently, when I investigated a problem caused by parallel execution of docker exec, I found the the problem was caused by runc. The weird part was when I replaced the runc with the one built by myself using the same commit, the problem was gone. After some digging, I found the one I built is different from the one shipped with containerd v1.2.0.

The containerd rpm was downloaded from here: https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.0-3.el7.x86_64.rpm

After unpacked it with rpm2cpio, I used ldd and objdump to find out its content:

[root@node sbin]# pwd
/root/containerd/1.2.0/usr/sbin
[root@node-143 sbin]# ldd ./runc
        linux-vdso.so.1 (0x00007ffda33d0000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc6d06af000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc6d048f000)
        libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fc6d0270000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc6cfe9a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc6d1680000)
[root@node-143 sbin]# objdump -t runc | grep -i openssl
0000000000ba3000 l     O .data.rel.ro   0000000000000020              go.itab.openssl.Error,error
...
0000000000287720 g     F .text  0000000000000017              fips_openssl_ia32_rdrand
0000000000269cd0 g     F .text  000000000000001f              FIPS_openssldie
000000000065f2f0 g     F .text  000000000000000b              OPENSSL_rdtsc

Questions:

1. The runc shipped with containerd v1.2.0 seems like statically linked to a libssl?
2. Why it use libdl?

I cannot find any text in the codebase related to libssl or libdl, it seems like it can only be injected with EXTRA_LDFLAGS ?

# quote from Makefile

runc: $(SOURCES)
	$(GO) build -buildmode=pie $(EXTRA_FLAGS) -ldflags "-X main.gitCommit=${COMMIT} -X main.version=${VERSION} $(EXTRA_LDFLAGS)" -tags "$(BUILDTAGS)" -o runc .

static: $(SOURCES)
	CGO_ENABLED=1 $(GO) build $(EXTRA_FLAGS) -tags "$(BUILDTAGS) netgo cgo static_build" -installsuffix netgo -ldflags "-w -extldflags -static -X main.gitCommit=${COMMIT} -X main.version=${VERSION} $(EXTRA_LDFLAGS)" -o runc .

Does anyone know the history?

[thaJeztah]

Those packages would've been built using the packaging scripts at this commit (or the commit after); https://github.com/docker/containerd-packaging/tree/efc8bdfed6e202db185797d17e6221e24149f861

All those versions you mentioned are EOL since a long time though, including CentOS 7, so I would highly recommend upgrading to something more current as there's various unpatched vulnerabilities in those versions.

[diabloneo]

Thanks.

After I read the packaging script, I found that the build process seems nothing special. But I found the docker image used in the building has a strange name dockereng/go-crypto-swap:centos-go1.10.4-92409f5 which implies it has something related to openssl library. Sadly, I cannot find the Dockerfile of this image. So I cannot confirm my guess. Did I guess correctly?

All those versions you mentioned are EOL since a long time though, including CentOS 7, so I would highly recommend upgrading to something more current as there's various unpatched vulnerabilities in those versions.

Thanks for this, too. We already upgraded the system.

[akhilerm]

Curious about the fips keywords that pop up in the symbols. Was runc built previously with FIPS compliance?

[thaJeztah]

Ah, yes! Missed that when I commented as I commented from my Phone, but that's correct indeed. I had to dig deep in memory as it's been a while, but that packaging repository was indeed closed source and part of the "Docker EE" (Docker Enterprise) pipeline. Docker EE was built with FIPS for which a special image was used, and because it depended on containerd.io, I think those packages were always built with FIPS (shared between Docker CE and Docker EE); docker/containerd-packaging#35.

When Docker Enterprise went to Mirantis, that was no longer the case, and the repository was open sourced (originally I think the intent was for that repository to be moved to the containerd org, but I was not involved in that effort); docker/containerd-packaging#136

[thaJeztah]

In case of interest; I think Mirantis still builds their packages with FIPS

[akhilerm]

Thank you for the historical context.