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.

(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

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.

I think it's still failing:

(root@n3 ~) $ rpm -qa | grep selinux
selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
container-selinux-1.12.5-14.el7.x86_64
libselinux-2.5-6.el7.x86_64
libselinux-utils-2.5-6.el7.x86_64
selinux-policy-3.13.1-102.el7_3.4.noarch
libselinux-python-2.5-6.el7.x86_64

$ 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
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

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.

To re-try, just do "kubeadm reset" followed by your next "kubeadm init".

This looks like a different issue.  You are not running a Privileged container or you ar enot labeling etcd correctly.

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.

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.

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?

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

https://bugzilla.redhat.com/show_bug.cgi?id=1413100 spun out for my separate later issue.

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.

https://rhn.redhat.com/errata/RHSA-2017-0116.html