Cannot attach to auto-started LXC containers in (Fedora) SELinux

Question

Environment: I am running Fedora 24 with LXC (2.0.6) containers inside and SELinux enabled.

Problem: Setting up Linux containers and starting them is all fine, and the same holds for attaching to a container via lxc-attach except for those containers that have been started by the autostart-feature of LXC (lxc.start.auto = 1 in its config file).

For any auto-started container I cannot attach to, I can lxc-stop and lxc-start it again, whereupon I can directly lxc-attach to that container.

What I've tried: I already checked the proposed solution from this bug-report, which consists of dnf-installing the container-selinux extensions, and adding the right label (container_runtime_exec_t) to the executables /usr/bin/lxc-* which includes lxc-attach. Though also proposed as possible solution, I have not added a label to the context of the base folder for my root-filesystems of all containers (chcon -Rt container_var_lib_t /var/lib/lxc).

Output: With manually started containers I have no problems to attach (lxc-attach -n name_of_container), but when I try to attach to a container which has been started automatically at system-boot, I get a message on the terminal like

lxc-attach: attach.c: lxc_attach_run_shell: 1325 Permission denied - failed to exec shell

while in the /var/log/audit/audit.log file I get a message like

type=AVC msg=audit(1484836169.882:2969): avc:  denied  { entrypoint } for  pid=7867 comm="lxc-attach" path="/bin/dash" dev="sda3" ino=10289 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0

If I look up the labels of the processes that run my containers (ps -eZ | grep lxc), I get

system_u:system_r:unconfined_service_t:s0 2794 ? 00:00:00 lxc-autostart

for auto-started containers, as compared with

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 6399 ? 00:00:00 lxc-start

for manually started containers.

My question: I'm a bit too new to SELinux, but what I can see from the output above is that the context in which the container runs after it has been started on system-boot is quite different than the context my lxc-attach runs in (the former context starts with scontext=system_u:... while the my current context would is tcontext=unconfined_u:... from the audit.log above).

That is why I have to ask someone to explain to me: What kind of mismatch causes this permission-denied? And: Can I fix this?

Answer 1

I looks like at the time of this event that your /bin/dash was associate with either an invalid or no selinux context at all.

Here lxc-attach complains that it failed to execute a shell:

lxc-attach: attach.c: lxc_attach_run_shell: 1325 Permission denied - failed to exec shell

The SELinux avc denial seems to confirm the above:

type=AVC msg=audit(1484836169.882:2969): avc:  denied  { entrypoint } for  pid=7867 comm="lxc-attach" path="/bin/dash" dev="sda3" ino=10289 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0

A few this to note in the event above:

The target file (path="/bin/dash") ended up with a special context (tcontext=unconfined_u:object_r:unlabeled_t:s0) used by SELinux for failover scenarios. At the event either /bin/dash located at inode 10289 on device sda3 was either associated with an invalid context, or no context at all.

Try to restorecon -RvF the context of /bin/dash at inode 10289 on device sda3. After you've done that see if the context is reset to something other than unconfined_u:object_r:unlabeled_t:s0 with ls -alZ

Answer 2

This worked for me:

ausearch -c 'lxc-attach' --raw | audit2allow -M my-lxcattach

semodule -i my-lxcattach.pp
# or 
semodule -X 300 -i my-lxcattach.pp

Extracted from here: https://bugzilla.redhat.com/show_bug.cgi?id=1405921