Bug 1577506 - SELinux denial preventing all docker containers from running
Summary: SELinux denial preventing all docker containers from running
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: container-selinux
Version: 28
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: 2018-05-12 14:52 UTC by lapseofreason0
Modified: 2018-05-16 14:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-16 14:19:19 UTC
Type: Bug


Attachments (Terms of Use)

Description lapseofreason0 2018-05-12 14:52:33 UTC
Description of problem:
An SELinux denial is preventing me from running any docker container. After disabling SELinux (setenforce 0) the containers run just fine. The problem only appeared recently, I was able to run containers just fine until last week or so (on F27, before upgrade).

Version-Release number of selected component (if applicable):
container-selinux.noarch           2:2.55-1.fc28                         @fedora
docker.x86_64                      2:1.13.1-51.git4032bd5.fc28           @fedora

How reproducible:
I have two separate systems with this bug, one with F28 and another one still on F27. I was not able to reproduce it with the F28 live image.

Steps to Reproduce:
1. docker run --rm -it centos:7 /bin/sh

Actual results:
[root@fedora ~]# docker run --rm -it centos:7 /bin/sh
[root@fedora ~]# echo $?
0

Info from SETroubleshoot:
---
SELinux is preventing sh from 'read, write' accesses on the chr_file tty.

[...]

Raw Audit Messages
type=AVC msg=audit(1526135524.946:807): avc:  denied  { read write } for  pid=16479 comm="sh" name="tty" dev="tmpfs" ino=301826 scontext=system_u:system_r:container_t:s0:c234,c488 tcontext=system_u:object_r:container_file_t:s0:c234,c488 tclass=chr_file permissive=0

Hash: sh,container_t,container_file_t,chr_file,read,write
---

Expected results:
Drop to shell from docker container.


Additional info:
There is an error when running "dnf reinstall container-selinux":
---
[...]
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Reinstalling     : container-selinux-2:2.55-1.fc28.noarch                 1/2 
  Running scriptlet: container-selinux-2:2.55-1.fc28.noarch                 1/2 
libsemanage.semanage_direct_commit: semanage_genhomedircon returned error code -1. (Connection timed out).
/usr/sbin/semodule:  Failed!
  Erasing          : container-selinux-2:2.55-1.fc28.noarch                 2/2 
  Running scriptlet: container-selinux-2:2.55-1.fc28.noarch                 2/2 
  Verifying        : container-selinux-2:2.55-1.fc28.noarch                 1/2 
  Verifying        : container-selinux-2:2.55-1.fc28.noarch                 2/2 

Reinstalled:
  container-selinux.noarch 2:2.55-1.fc28                                        

Complete!
---
The home dir of both affected systems is a bind mount, I don't know whether this could have something to do with it.

Comment 1 lapseofreason0 2018-05-14 19:20:48 UTC
It seems to be a regression compared to version 2.52, as downgrading to container-selinux-2.52-1.fc27 and re-loading the module with semodule -i fixes the bug.

Comment 2 Daniel Walsh 2018-05-14 20:10:06 UTC
This looks like you are volume mounting a device from the host into the container, this device was previously labeled to run with a different container?
What is the docker command you are executing?

Comment 3 lapseofreason0 2018-05-15 05:48:23 UTC
This happens with any docker container, regardless of whether it has volumes or not. For example, running

docker run --rm -it centos:7 /bin/sh

produces

type=AVC msg=audit(1526363071.674:309): avc:  denied  { read write } for  pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0
type=AVC msg=audit(1526363071.674:310): avc:  denied  { read write } for  pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0
type=AVC msg=audit(1526363071.674:311): avc:  denied  { read write } for  pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0
type=AVC msg=audit(1526363071.674:312): avc:  denied  { read write } for  pid=4816 comm="sh" path="/2" dev="devpts" ino=5 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0
type=AVC msg=audit(1526363071.685:314): avc:  denied  { read write } for  pid=4816 comm="sh" name="tty" dev="tmpfs" ino=60022 scontext=system_u:system_r:container_t:s0:c233,c993 tcontext=system_u:object_r:container_file_t:s0:c233,c993 tclass=chr_file permissive=0

Comment 4 Daniel Walsh 2018-05-15 14:23:31 UTC
Looks like you somehow got your ttys mislabeled?

On Host

 ls -lZ /dev/pts/
total 0
crw--w----. 1 dwalsh tty  unconfined_u:object_r:user_devpts_t:s0 136, 0 May 15 10:23 0
crw--w----. 1 dwalsh tty  unconfined_u:object_r:user_devpts_t:s0 136, 1 May  8 08:08 1
crw--w----. 1 dwalsh tty  unconfined_u:object_r:user_devpts_t:s0 136, 2 May  8 07:54 2
crw--w----. 1 dwalsh tty  unconfined_u:object_r:user_devpts_t:s0 136, 3 May  8 08:40 3
crw--w----. 1 dwalsh tty  unconfined_u:object_r:user_devpts_t:s0 136, 4 May 15 09:48 4
c---------. 1 root   root system_u:object_r:devpts_t:s0            5, 2 Apr 20 05:18 ptmx

Comment 5 lapseofreason0 2018-05-15 16:55:44 UTC
Apart from the fact that I only have one it is similar to yours:

[root@fedora user]# ls -lZ /dev/pts/
total 0
crw--w----. 1 user tty  unconfined_u:object_r:user_devpts_t:s0 136, 0 May 15 18:51 0
c---------. 1 root  root system_u:object_r:devpts_t:s0            5, 2 May 15 14:52 ptmx

Comment 6 Daniel Walsh 2018-05-15 20:48:46 UTC
find /dev -context "*:container_file_t:*" 

Does this show anything?

If not

find / -context "*:container_file_t:s0:c233,c993"

Comment 7 lapseofreason0 2018-05-16 06:18:04 UTC
No, they both don't find anything:

[root@fedora user]# find /dev -context "*:container_file_t:*" 
[root@fedora user]# find / -context "*:container_file_t:s0:c233,c993"
find: ‘/run/user/1000/gvfs’: Permission denied

I just noticed that after running "semodule -i /usr/share/selinux/packages/container.pp.bz2" it is working again. When I remove it again with "semodule -X 400 -r container" it is still working. I upgraded the second system and tried the same there, it is working too.

Not sure what the problem was, could it be that the policy was not loaded correctly on upgrade?

Comment 8 Daniel Walsh 2018-05-16 13:19:18 UTC
I doubt it, from the AVC's you reported it definitely looked like one containers tty's leaking into another containers.  Anyways if you can't get this to happen again. I guess we can close the bugzilla until it does happen again.

Comment 9 lapseofreason0 2018-05-16 14:19:19 UTC
Sounds good, thanks a lot for your help!

There were definitely no other containers though, I wasn't able to start any until today.


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