runc icon indicating copy to clipboard operation
runc copied to clipboard

fix failure when selinux enabled in old kernel

Open lifubang opened this issue 5 years ago • 10 comments

Signed-off-by: lifubang [email protected]

I think #2032 fixed the problem on disabled SELinux Machines. But on enabled SELinux Machines with some old kernels, it still be fail when selinuxLabel is empty.

So, I think we should add selinuxLabel check in runc, it will be more safe to run.

And I will send a PR to selinux project soon.

lifubang avatar Apr 04 '19 08:04 lifubang

Please see https://github.com/opencontainers/selinux/pull/50 The fail kernel is: 3.10.0-862.el7.x86_64 in RedHat Enterprise Linux 7.5 I think 3.10.0 kernel is still used by lots of users, especially in some cloud.

lifubang avatar Apr 04 '19 08:04 lifubang

@rhatdan I would've suggested doing both checks, but if you're okay with failures on (very) old SELinux systems that's fine.

And I think @cyphar has pointed it out in https://github.com/opencontainers/selinux/pull/49#issuecomment-479326189.

lifubang avatar Apr 04 '19 08:04 lifubang

As PR https://github.com/opencontainers/selinux/pull/50 is closed by @rhatdan . Please see https://github.com/opencontainers/selinux/pull/52

@cyphar PTAL

lifubang avatar Apr 04 '19 15:04 lifubang

This patch doesn't make much sense to me -- old kernels will give you failures because /proc/self/attr/keycreate doesn't exist. So, if you run runc with an SELinux label you will still end up with -ENOENT. This would only fix cases where you are running containers without an explicit SELinux label on an SELinux-enabled system -- which is not the default under Docker/cri-o/podman/etc (by default they all have SELinux labels).

I would prefer to just wait for opencontainers/selinux#52 to be resolved.

cyphar avatar Apr 05 '19 14:04 cyphar

So, if you run runc with an SELinux label you will still end up with -ENOENT.

Oh, my god, too many things to consider. So, we should not be hurry, just think more.

I would prefer to just wait for opencontainers/selinux#52 to be resolved.

Ok, let's wait. Thanks.

lifubang avatar Apr 05 '19 15:04 lifubang

OK this is what I just saw on CentOS 7 system (with the latest CentOS 7 kernel, 3.10.0-957.12.2.el7.x86_64). This is from strace on containerd:

20396 openat(AT_FDCWD, "/proc/self/attr/keycreate", O_WRONLY|O_CLOEXEC) = 7
20396 epoll_ctl(6, EPOLL_CTL_ADD, 7, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3687386888, u64=139826347708168}}) = -1 EPERM (Operation not permitted)
20396 epoll_ctl(6, EPOLL_CTL_DEL, 7, 0xc00014aedc) = -1 EPERM (Operation not permitted)
20396 write(7, "", 0)                   = -1 EACCES (Permission denied)
20396 close(7)                          = 0
20396 write(3, "{\"type\":\"procError\"}", 20) = 20

this EACCES error on write() is kinda flaky, it sometimes disappears when I upgrade or downgrade container-selinux package (apparently its version doesn't play any role which is the weirdest part...)

kolyshkin avatar Jun 10 '19 20:06 kolyshkin

What AVC's are you seeing?

ausearch -m avc -ts recent

rhatdan avatar Jun 10 '19 21:06 rhatdan

[root@kir-ce7-selinux-02 ~]# docker run hello-world
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"write /proc/self/attr/keycreate: permission denied\"": unknown.

[root@kir-ce7-selinux-02 ~]# ausearch -m avc -ts recent
----
time->Tue Jun 11 00:50:06 2019
type=PROCTITLE msg=audit(1560214206.491:3314): proctitle=72756E6300696E6974
type=SYSCALL msg=audit(1560214206.491:3314): arch=c000003e syscall=1 success=no exit=-13 a0=7 a1=5579f5a61158 a2=0 a3=0 items=0 ppid=20958 pid=20967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="runc:[2:INIT]" exe="/" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=AVC msg=audit(1560214206.491:3314): avc:  denied  { create } for  pid=20967 comm="runc:[2:INIT]" scontext=system_u:system_r:unconfined_service_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=key permissive=0

[root@kir-ce7-selinux-02 ~]# rpm -q container-selinux
container-selinux-2.95-2.el7_6.noarch

kolyshkin avatar Jun 11 '19 00:06 kolyshkin

So you are running runc directly as a service in a systemd unit file?

Or are you running this under docker? Either way it should not be running as unconfined_service_t, it should be running as container_runtime_t. (Not sure if this would work either with that policy.)

In Fedora we currently have sesearch -A -s container_runtime_t -t unlabeled_t -c key allow container_runtime_t unlabeled_t:key { create link read search setattr view write };

rhatdan avatar Jun 11 '19 18:06 rhatdan

@lifubang what version of docker are you running?

It might be the case that your containerd and/or runc binaries are mislabeled.

To test:

ls -Z /usr/{s,}bin/{containerd,runc,docker}
ps axZ | grep -E 'containerd|dockerd'

Both commands should have container_runtime_exec_t in every line corresponding to containerd, dockerd, and runc binaries, and container_runtime_t for processes.

If this is not the case,

yum update container-selinux
restorecon /usr/{s,}bin/{containerd,runc,docker}
systemctl restart docker
systemctl restart containerd

should fix the issue.

kolyshkin avatar Jun 12 '19 00:06 kolyshkin