Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1405921 - SELinux is preventing lxc-attach from entrypoint access on the file /usr/bin/bash
Summary: SELinux is preventing lxc-attach from entrypoint access on the file /usr/bin/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: container-selinux
Version: 25
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-19 07:50 UTC by srakitnican
Modified: 2017-03-14 02:21 UTC (History)
26 users (show)

Fixed In Version: container-selinux-2.9-1.fc25 container-selinux-2.10-1.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-13 23:55:07 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description srakitnican 2016-12-19 07:50:23 UTC 
Description of problem: Attaching to a lxc container located under /var/lib/lxc/ is not possible.


SELinux is preventing lxc-attach from entrypoint access on the file /usr/bin/bash.

*****  Plugin restorecon (94.8 confidence) suggests   ************************

If you want to fix the label. 
/usr/bin/bash default label should be shell_exec_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /usr/bin/bash

*****  Plugin catchall_labels (5.21 confidence) suggests   *******************

If you want to allow lxc-attach to have entrypoint access on the bash file
Then you need to change the label on /usr/bin/bash
Do
# semanage fcontext -a -t FILE_TYPE '/usr/bin/bash'
where FILE_TYPE is one of the following: bin_t, shell_exec_t, usr_t.
Then execute:
restorecon -v '/usr/bin/bash'


*****  Plugin catchall (1.44 confidence) suggests   **************************

If you believe that lxc-attach should be allowed entrypoint access on the bash file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'lxc-attach' --raw | audit2allow -M my-lxcattach
# semodule -X 300 -i my-lxcattach.pp

Additional Information:
Source Context                system_u:system_r:unconfined_service_t:s0
Target Context                unconfined_u:object_r:var_lib_t:s0
Target Objects                /usr/bin/bash [ file ]
Source                        lxc-attach
Source Path                   lxc-attach
Port                          <Unknown>
Host                          rawhide
Source RPM Packages           
Target RPM Packages           bash-4.3.43-4.fc25.x86_64
Policy RPM                    selinux-policy-3.13.1-225.3.fc25.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     rawhide
Platform                      Linux rawhide 4.8.13-300.fc25.x86_64 #1 SMP Fri
                              Dec 9 14:52:00 UTC 2016 x86_64 x86_64
Alert Count                   3
First Seen                    2016-12-19 08:37:49 CET
Last Seen                     2016-12-19 08:42:19 CET
Local ID                      8ef4ba24-bb86-4bb6-b006-7fc1748bf679

Raw Audit Messages
type=AVC msg=audit(1482133339.979:1258): avc:  denied  { entrypoint } for  pid=17506 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0


Hash: lxc-attach,unconfined_service_t,var_lib_t,file,entrypoint


Version-Release number of selected component (if applicable):


How reproducible:
lxc-attach --name=<container-name>


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


Expected results:
For command lxc-attach to be able to attach to a container by default.


Additional info:
Command restorecon -Rv /var/lib/lxc/ did not fix the issue.
Comment 1 srakitnican 2016-12-19 07:52:21 UTC 
Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-225.3.fc25.noarch
Comment 2 Daniel Walsh 2016-12-19 22:25:22 UTC 
If you change the label of lxc-attach to container_runtime_exec_t does it fix the issue?

chcon -t container_runtime_exec_t /usr/bin/lxc-attach
Comment 3 srakitnican 2016-12-20 07:14:02 UTC 
I am unable to change it, not sure why.

$ ls -lZ /usr/bin/lxc-attach
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 20320 Pro  5 12:30 /usr/bin/lxc-attach
$ sudo chcon -t container_runtime_exec_t /usr/bin/lxc-attach
chcon: failed to change context of '/usr/bin/lxc-attach' to ‘system_u:object_r:container_runtime_exec_t:s0’: Invalid argument
Comment 4 srakitnican 2016-12-20 07:29:36 UTC 
Because it doesn't seems to exist.

$ sudo semanage fcontext -l | grep container_runtime_exec_t
$
Comment 5 Daniel Walsh 2016-12-20 13:57:57 UTC 
dnf -y install container-selinux

Then try it.
Comment 6 srakitnican 2016-12-20 14:19:18 UTC 
Ok, I've installed container-selinux and changed label for lxc-attach, same thing is happening, SELinux alert and error message.
Comment 7 Daniel Walsh 2016-12-20 14:28:27 UTC 
What AVC are you getting now?
Comment 8 srakitnican 2016-12-20 15:16:59 UTC 
$ ls -lZ /usr/bin/lxc-attach 
-rwxr-xr-x. 1 root root system_u:object_r:container_runtime_exec_t:s0 20320 Dec  5 12:30 /usr/bin/lxc-attach
$ sudo lxc-attach --name=fedora-dev
lxc-attach: attach.c: lxc_attach_run_shell: 1325 Permission denied - failed to exec shell

SELinux is preventing lxc-attach from entrypoint access on the file /usr/bin/bash.

*****  Plugin restorecon (94.8 confidence) suggests   ************************

If you want to fix the label. 
/usr/bin/bash default label should be shell_exec_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /usr/bin/bash

*****  Plugin catchall_labels (5.21 confidence) suggests   *******************

If you want to allow lxc-attach to have entrypoint access on the bash file
Then you need to change the label on /usr/bin/bash
Do
# semanage fcontext -a -t FILE_TYPE '/usr/bin/bash'
where FILE_TYPE is one of the following: bin_t, shell_exec_t, usr_t.
Then execute:
restorecon -v '/usr/bin/bash'


*****  Plugin catchall (1.44 confidence) suggests   **************************

If you believe that lxc-attach should be allowed entrypoint access on the bash file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'lxc-attach' --raw | audit2allow -M my-lxcattach
# semodule -X 300 -i my-lxcattach.pp

Additional Information:
Source Context                system_u:system_r:unconfined_service_t:s0
Target Context                unconfined_u:object_r:var_lib_t:s0
Target Objects                /usr/bin/bash [ file ]
Source                        lxc-attach
Source Path                   lxc-attach
Port                          <Unknown>
Host                          rawhide
Source RPM Packages           
Target RPM Packages           bash-4.3.43-4.fc25.x86_64
Policy RPM                    selinux-policy-3.13.1-225.3.fc25.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     rawhide
Platform                      Linux rawhide 4.8.14-300.fc25.x86_64 #1 SMP Mon
                              Dec 12 16:31:04 UTC 2016 x86_64 x86_64
Alert Count                   14
First Seen                    2016-12-19 08:37:49 CET
Last Seen                     2016-12-20 16:14:54 CET
Local ID                      8ef4ba24-bb86-4bb6-b006-7fc1748bf679

Raw Audit Messages
type=AVC msg=audit(1482246894.908:780): avc:  denied  { entrypoint } for  pid=28947 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0


Hash: lxc-attach,unconfined_service_t,var_lib_t,file,entrypoint
Comment 9 Daniel Walsh 2016-12-20 16:10:30 UTC 
chcon -Rt container_var_lib_t /var/lib/lxc

Should fix this issue.
Comment 10 srakitnican 2016-12-20 16:19:55 UTC 
Umm, I am seeing the same issue

type=AVC msg=audit(1482250671.868:894): avc:  denied  { entrypoint } for  pid=31225 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1482250671.868:895): avc:  denied  { entrypoint } for  pid=31225 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
Comment 11 Daniel Walsh 2016-12-20 16:24:03 UTC 
Looks like lxc-attach is not labeled as container_runtime_exec_t?
Comment 12 srakitnican 2016-12-20 17:19:37 UTC 
Yes, I did restorecon on it, but it was the same with it.

$ ls -lZ /usr/bin/lxc-attach 
-rwxr-xr-x. 1 root root system_u:object_r:container_runtime_exec_t:s0 20320 Pro  5 12:30 /usr/bin/lxc-attach
$ ls -ldZ /var/lib/lxc
drwxr-xr-x. 3 root root system_u:object_r:container_var_lib_t:s0 4096 Pro  5 12:30 /var/lib/lxc

type=AVC msg=audit(1482254207.040:942): avc:  denied  { entrypoint } for  pid=32709 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1482254207.040:943): avc:  denied  { entrypoint } for  pid=32709 comm="lxc-attach" path="/usr/bin/bash" dev="sdc4" ino=1329114 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0
Comment 13 Daniel Walsh 2016-12-20 18:14:25 UTC 
What does the unit file look like?  Is there something about an unconfined_service_t in the unit file?
Comment 14 Daniel Walsh 2016-12-20 18:16:33 UTC 
How did the original container get started?  This looks like we would label the original container lxc-start as container_runtime_exec_t also.
I am adding labels for all /usr/bin/lxc-* code to container_runtime_exec_t, which should cause all of the container processes to be container_runtime_t.  No unconfined_service_t.

You would need to stop and start the container again.
Comment 15 srakitnican 2016-12-20 18:39:14 UTC 
Sorry I don't understand, which unit file are you referring to? If systemd unit file it is standard unmodified file from Fedora repository.

I have found that "[lxc monitor]" runs under unconfined_service_t

$ ps -Z 2038
LABEL                             PID TTY      STAT   TIME COMMAND
system_u:system_r:unconfined_service_t:s0 2038 ? Ss   0:00 [lxc monitor] /var/lib/lxc fedora-dev


$ for proc in $(sudo find /proc/ -context *unconfined_service_t* | cut -f1-3 -d / | sort -u); do cat $proc/cmdline; echo; done
find: getfilecon failed: ‘/proc/3606/task/3669/fdinfo/134’: No such file or directory
[lxc monitor] /var/lib/lxc fedora-dev
/sbin/init
/usr/lib/systemd/systemd-journald
/usr/lib/systemd/systemd-logind
/usr/bin/dbus-daemon--system--address=systemd:--nofork--nopidfile--systemd-activation--syslog-only
/usr/sbin/rsyslogd-n
/sbin/agetty--nocleartty3linux
/sbin/agetty--noclear--keep-baudconsole115200,38400,9600vt220
/sbin/agetty--nocleartty4linux
/sbin/agetty--noclear--keep-baudpts/1115200,38400,9600vt220
/sbin/agetty--noclear--keep-baudpts/0115200,38400,9600vt220
/sbin/agetty--nocleartty2linux
/sbin/agetty--noclear--keep-baudpts/3115200,38400,9600vt220
/sbin/agetty--noclear--keep-baudpts/2115200,38400,9600vt220
/sbin/agetty--nocleartty1linux
/usr/sbin/sshd
/sbin/dhclient-Hfedora-dev-1-q-lf/var/lib/dhclient/dhclient--eth0.lease-pf/var/run/dhclient-eth0.pideth0

Yes I am running it this entire time as a service from lxc.service.
Comment 16 srakitnican 2016-12-20 18:43:42 UTC 
Ok, following worked.

$ sudo chcon -t container_runtime_exec_t /usr/bin/lxc-*
Comment 17 Lukas Vrabec 2017-01-09 09:28:12 UTC 
This shoudl be fixed in docker package.
Comment 18 srakitnican 2017-01-09 09:34:52 UTC 
(In reply to Lukas Vrabec from comment #17)
> This shoudl be fixed in docker package.

I don't have a "docker" package installed, shouldn't lxc work without docker?
Comment 19 Daniel Walsh 2017-01-09 15:23:31 UTC 
You need to install container-selinux.  Which is being separated out into a separate package.

lxc should probbaly require this package going forward.
Comment 20 Michael Göhler 2017-02-15 12:27:38 UTC 
I have the same issue on CentOS 7.

I've tried the following:

- installed container-selinux
- set container_runtime_exec_t on /usr/bin/lxc-*
- set container_var_lib_t on /var/lib/lxc (recursive)

But I still get unconfined_service_t for containers started by lxc.service

# ps -efZ | grep lxc
system_u:system_r:unconfined_service_t:s0 root 2982 1  0 13:08 ?       00:00:00 /usr/bin/lxc-autostart -g onboot,

# for proc in $(sudo find /proc/ -context *unconfined_service_t* | cut -f1-3 -d / | sort -u); do tr '\0' ' ' <$proc/cmdline; echo; done
/usr/bin/lxc-autostart -g onboot,
/sbin/init
/usr/lib/systemd/systemd-journald
/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
/usr/lib/systemd/systemd-logind
/usr/sbin/rsyslogd -n
/sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220
/usr/sbin/sshd
/sbin/dhclient -H centos_lxc_01 -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid eth0
Comment 21 Daniel Walsh 2017-02-16 14:21:22 UTC 
Does your service unit run lxc-autostart directly or is it executing some other command. 

The transition right now is for systemd running as init_t executing something labeled as bin_t will run unconfined_service_t.  If it executes something labeled container_runtime_exec_t it will run it as container_runtime_t.
Comment 22 Michael Göhler 2017-02-16 15:54:11 UTC 
The service runs /usr/libexec/lxc/lxc-autostart-helper, which is a sysvinit script labeled bin_t. Changing the label of the shell script doesn't help.
Comment 23 Daniel Walsh 2017-02-20 21:52:52 UTC 
Changing it to initrc_exec_t or container_runtime_exec_t doesn't help?
Comment 24 Michael Göhler 2017-02-21 09:11:40 UTC 
My fault. The label of /usr/libexec/lxc/lxc-autostart-helper is reset to bin_t on reboot.

After a reboot to enforce selinux:

# chcon -t container_runtime_exec_t /usr/libexec/lxc/lxc-autostart-helper
# systemctl restart lxc
# ps -eZ | grep lxc-autostart
system_u:system_r:container_runtime_t:s0 3488 ? 00:00:00 lxc-autostart
Comment 25 Daniel Walsh 2017-02-24 15:23:17 UTC 
semanage fcontext -a -t container_runtime_exec_t /usr/libexec/lxc/lxc-autostart-helper
restorecon -R -v container_runtime_exec_t /usr/libexec/lxc/lxc-autostart-helper

Should tell the system to not set it back to bin_t.
Comment 26 Daniel Walsh 2017-02-24 15:25:43 UTC 
I just set this up as the default labeling for content in this directory in the container-selinux repo.
Comment 27 Fedora Update System 2017-02-27 17:18:45 UTC 
container-selinux-2.9-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-018d2c13f7
Comment 28 Fedora Update System 2017-03-01 02:53:01 UTC 
container-selinux-2.9-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-018d2c13f7
Comment 29 srakitnican 2017-03-01 09:45:00 UTC 
I've installed container-selinux-2.9-1.fc25 and did "touch /.autorelabel && reboot". I still have issues attaching to a running container with lxc-attach.

Seems the issue is now that process from lxc.service is labeled as unconfined_service_t.

SELinux is preventing lxc-attach from entrypoint access on the file /usr/bin/bash.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/usr/bin/bash default label should be shell_exec_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /usr/bin/bash

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that lxc-attach should be allowed entrypoint access on the bash file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'lxc-attach' --raw | audit2allow -M my-lxcattach
# semodule -X 300 -i my-lxcattach.pp

Additional Information:
Source Context                system_u:system_r:unconfined_service_t:s0
Target Context                unconfined_u:object_r:container_var_lib_t:s0
Target Objects                /usr/bin/bash [ file ]
Source                        lxc-attach
Source Path                   lxc-attach
Port                          <Unknown>
Host                          host
Source RPM Packages           
Target RPM Packages           bash-4.3.43-4.fc25.x86_64
Policy RPM                    selinux-policy-3.13.1-225.11.fc25.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     host
Platform                      Linux host 4.9.12-200.fc25.x86_64 #1 SMP
                              Thu Feb 23 19:31:49 UTC 2017 x86_64 x86_64
Alert Count                   1
First Seen                    2017-03-01 10:35:04 CET
Last Seen                     2017-03-01 10:35:04 CET
Local ID                      797269fc-0887-40a5-a5f5-92eddc72148a

Raw Audit Messages
type=AVC msg=audit(1488360904.991:258): avc:  denied  { entrypoint } for  pid=3407 comm="lxc-attach" path="/usr/bin/bash" dev="sda2" ino=941481 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=file permissive=0


Hash: lxc-attach,unconfined_service_t,container_var_lib_t,file,entrypoint


$ ps -auxZ | grep lxc
system_u:system_r:unconfined_service_t:s0 root 1968 0.0  0.0 24496 2732 ?      Ss   10:32   0:00 [lxc monitor] /var/lib/lxc fedora-dev


$ ls -Z /usr/bin/lxc*
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-attach
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-autostart
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-cgroup
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-checkconfig
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-checkpoint
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-config
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-console
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-copy
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-create
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-destroy
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-device
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-execute
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-freeze
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-info
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-ls
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-monitor
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-snapshot
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-start
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-stop
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-top
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-unfreeze
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-unshare
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-usernsexec
system_u:object_r:container_runtime_exec_t:s0 /usr/bin/lxc-wait
Comment 30 Daniel Walsh 2017-03-01 19:25:52 UTC 
ls -lZ /usr/libexec/lxc/*
Comment 31 srakitnican 2017-03-01 23:54:11 UTC 
$ ls -lZ /usr/libexec/lxc/*
-rwxr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0   521 Sij 29 13:20 /usr/libexec/lxc/lxc-apparmor-load
-rwxr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0  2969 Sij 29 13:20 /usr/libexec/lxc/lxc-containers
-rwxr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0 19672 Sij 29 13:20 /usr/libexec/lxc/lxc-monitord
-rwxr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0  6357 Sij 29 13:20 /usr/libexec/lxc/lxc-net
-rwsr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0 40408 Sij 29 13:20 /usr/libexec/lxc/lxc-user-nic
/usr/libexec/lxc/hooks:
total 12
-rwxr-xr-x. 1 root root unconfined_u:object_r:bin_t:s0 11240 Sij 29 13:20 unmount-namespace
Comment 32 Fedora Update System 2017-03-02 01:21:12 UTC 
container-selinux-2.9-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Comment 33 Daniel Walsh 2017-03-02 14:52:04 UTC 
matchpathcon /usr/libexec/lxc/*
/usr/libexec/lxc/hooks	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-apparmor-load	system_u:object_r:container_runtime_exec_t:s0
/usr/libexec/lxc/lxc-containers	system_u:object_r:container_runtime_exec_t:s0
/usr/libexec/lxc/lxc-monitord	system_u:object_r:container_runtime_exec_t:s0
/usr/libexec/lxc/lxc-net	system_u:object_r:container_runtime_exec_t:s0
/usr/libexec/lxc/lxc-user-nic	system_u:object_r:container_runtime_exec_t:s0

# rpm -q container-selinux
container-selinux-2.9-1.fc26.noarch
Comment 34 srakitnican 2017-03-02 20:00:45 UTC 
It seems F25 package is slightly different?

$ matchpathcon /usr/libexec/lxc/*
/usr/libexec/lxc/hooks	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-apparmor-load	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-containers	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-monitord	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-net	system_u:object_r:bin_t:s0
/usr/libexec/lxc/lxc-user-nic	system_u:object_r:bin_t:s0
Comment 35 Daniel Walsh 2017-03-02 21:30:21 UTC 
could you make sure it was installed successfully?

dnf reinstall container-selinux
Comment 36 srakitnican 2017-03-02 22:40:14 UTC 
Sure, I did that but it seems there was no effect, matchpathcon /usr/libexec/lxc/* shows the same result as before.

I take a look at upstream container-selinux project, and could not find any security context information for /usr/libexec/lxc.* on commit that 2:9.1-1 branch for F25 is based on:

https://github.com/projectatomic/container-selinux/blob/08bb6e0a1a63b1312c88c2e201b58aeb0ffd5467/container.fc


F26 branch however, seems to have correct commit

https://github.com/projectatomic/container-selinux/blob/8f8caa66c11f8657ebf8ae50d7221ee3a97ac7d3/container.fc
Comment 37 Daniel Walsh 2017-03-02 22:45:39 UTC 
Yup sorry it looks like I need a new version.

commit 46648d73b05fa0d0a5ba1b35be27a8417b6d46c5
Author: Daniel J Walsh <dwalsh>
Date:   Fri Feb 24 10:25:08 2017 -0500

    Label files under /usr/libexec/lxc as container_runtime_exec_t

commit 08bb6e0a1a63b1312c88c2e201b58aeb0ffd5467
Author: Daniel J Walsh <dwalsh>
Date:   Sun Feb 12 10:48:39 2017 -0500

    bUMP TO V2.9
Comment 38 Daniel Walsh 2017-03-02 22:48:21 UTC 
Building container-selinux-2.10...
Comment 39 srakitnican 2017-03-02 23:34:55 UTC 
container-selinux-2.10-1.fc25, seems to work fine, thanks.
Comment 40 Fedora Update System 2017-03-03 12:51:34 UTC 
container-selinux-2.10-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-02001fefbc
Comment 41 Fedora Update System 2017-03-03 22:49:55 UTC 
container-selinux-2.10-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-02001fefbc
Comment 42 Fedora Update System 2017-03-13 23:55:07 UTC 
container-selinux-2.10-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Comment 43 Fedora Update System 2017-03-14 02:21:24 UTC 
container-selinux-2.10-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.