Bug 1412385 - [extras-rhel-7.3.2] selinux issues
Summary: [extras-rhel-7.3.2] selinux issues
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Lokesh Mandvekar
QA Contact: atomic-bugs@redhat.com
Depends On:
Blocks: 1387497 1412386
TreeView+ depends on / blocked
Reported: 2017-01-11 22:16 UTC by Lokesh Mandvekar
Modified: 2019-03-06 01:10 UTC (History)
7 users (show)

Fixed In Version: docker-2:1.12.5-13.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1412386 (view as bug list)
Last Closed: 2017-01-17 20:46:01 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0116 0 normal SHIPPED_LIVE Moderate: docker security, bug fix, and enhancement update 2017-01-18 01:39:43 UTC

Description Lokesh Mandvekar 2017-01-11 22:16:45 UTC
Description of problem:

See: https://github.com/kubernetes/kubeadm/issues/107#issuecomment-271901243

Comment 4 Daniel Walsh 2017-01-12 13:54:41 UTC
Simplest thing is to use setools-console

# yum install setools-console
# sesearch -A -s spc_t -t svirt_sandbox_file_t -p entrypoint

The error they were seeing was that there was not rules returned.
With this fix, SELinux should have these rules and therefore allow the transition.

Comment 5 Luwen Su 2017-01-12 14:15:08 UTC
(In reply to Daniel Walsh from comment #4)
> Simplest thing is to use setools-console
> # yum install setools-console
> # sesearch -A -s spc_t -t svirt_sandbox_file_t -p entrypoint
> The error they were seeing was that there was not rules returned.
> With this fix, SELinux should have these rules and therefore allow the
> transition.

Thanks Dan!
And i'd like to keep this open for a while for more testing. 

In docker-1.12.5-14.el7.x86_64
# sesearch -A -s spc_t -t svirt_sandbox_file_t -p entrypoint
Found 2 semantic av rules:
   allow filesystem_unconfined_type filesystem_type : chr_file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod open audit_access } ; 
   allow spc_t svirt_sandbox_file_t : file entrypoint ; 

The version the reporter uses  1.10.3-46.el7.14
# sesearch -A -s spc_t -t svirt_sandbox_file_t -p entrypoint
ERROR: could not find datum for type spc_t

Comment 6 Daniel Walsh 2017-01-12 14:28:13 UTC
Just to make sure everyting is working.

# sesearch -A -s spc_t -p entrypoint

To show that their are other entrypoints for spc_t, just not the container image type. svirt_sandbox_file_t.

BTW In the future (RHEL7.4), this type will be changing to container_file_t.

Comment 7 Devan Goodwin 2017-01-12 19:48:50 UTC
I think it's still failing:

(root@n3 ~) $ rpm -qa | grep selinux

$ tail -f /var/log/audit/audit.log | grep denied
type=AVC msg=audit(1484249804.933:1300): avc:  denied  { write } for  pid=5817 comm="etcd" name="etcd" dev="dm-0" ino=1048971 scontext=system_u:system_r:svirt_lxc_net_t:s0:c247,c296 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir

I'm told there is some confusion over the reproducer, it's really just installing kubeadm, and running "kubeadm init". (https://kubernetes.io/docs/getting-started-guides/kubeadm/) Skipping the setenforce 0 obviously which we're trying to get out of these instructions, though that is not going so well.

Reproduce instructions: 

cat <<EOF > /etc/yum.repos.d/kubernetes.repo

yum install -y docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker && systemctl start docker
systemctl enable kubelet && systemctl start kubelet

Then just run kubeadm init.

The bug will cause it to hang at "waiting for control plane" and you will see the above denial in audit.log.

If it completes with setenforce 1, then the bug is fixed.

Comment 8 Devan Goodwin 2017-01-12 19:50:50 UTC
To re-try, just do "kubeadm reset" followed by your next "kubeadm init".

Comment 9 Daniel Walsh 2017-01-12 21:30:53 UTC
This looks like a different issue.  You are not running a Privileged container or you ar enot labeling etcd correctly.

Comment 10 Daniel Walsh 2017-01-12 21:33:02 UTC
Your container is running as svirt_lxc_net_t, which is a confined type.  It should be running privileged which would be spc_t, if this is a privileged container.

The original bug was about not being able to run spc_t containers.

Comment 11 Devan Goodwin 2017-01-13 13:21:03 UTC
I'm running the same version of kubeadm as the reporter and it should therefore specify the etcd pod should run as spc_t. However I'm trying to test at Lokesh' request and all I had available was RHEL 7.2 vagrant vms, I suspect trying to just install those rpms is not working, is it possible the spc_t would be ignored on RHEL 7.2 and default to svirt_lxc_net_t?

I will try with a full yum update but indeed the error I'm hitting isn't the same so I'm not sure I'm set up to test this properly.

If anyone involved can verify the reproducer in comment #7 no longer occurs then we are good.. In meantime I will try to update my vm and see if it gets better.

Comment 12 Devan Goodwin 2017-01-13 13:58:42 UTC
I upgraded everything to RHEL 7.3, my etcd pod is still getting denied with the error in comment #7. Is there any possibility something is busted with trying to run containers using spc_t causing them to run as svirt_lxc_net_t? kubeadm version is the same, the etcd pod definition in there is configured to run as spc_t, as it was on CentOS where this was reported.

Can anyone get through the steps in comment #7 successfully with selinux enforcing?

Comment 13 Daniel Walsh 2017-01-13 14:04:50 UTC
We should fix etcd requiring spc_t, but I have a feeling this is an issue with kubeadm not sending down the proper flags to docker to run the container.
If you run the container in permissive mode and then inspect the container, is it running with the privileged flag?

BTW The problem being reported is that the /var/lib/etcd? directory mounted into the container has the wrong SELinux context on it.  From a docker point of view adding the :Z to the volume mount would fix this issue.

You could go in behind the scenes and fix this by executing

chcon -t svirt_sandbox_file_t -R /var/lib/etcd

Comment 14 Devan Goodwin 2017-01-13 15:50:03 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1413100 spun out for my separate later issue.

Comment 16 errata-xmlrpc 2017-01-17 20:46:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.