I have a container whose entrypoint uses 'su' to drop its privileges. The run of the container triggers an AVC, but the container seems to run normally.
That is on a server, and the SELinux Troubleshooter sends me emails (see the attachment).
Two questions:
1/ Is there a way to report bugs to Bugzilla using the command line sealert tool (or another command line tool), like what we can do using the GUI?
2/ What should I do to fix that issue, if that is one?
I copy-paste here the AVC (the attached email have more information):
type=AVC msg=audit(1434542552.136:6332403): avc: denied { search } for pid=11266 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
type=SYSCALL msg=audit(1434542552.136:6332403): arch=x86_64 syscall=keyctl success=no exit=EACCES a0=0 a1=fffffffd a2=0 a3=7f7c50a132f0 items=0 ppid=11065 pid=11266 auid=4294967295 uid=500 gid=501 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=su exe=/usr/bin/su subj=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 key=(null)
This is a leaked key from cron into the container. I have no idea how the crond keyring got into the container. Did you somehow restart docker via crond?
On 06/17/2015 08:46 AM, Laurent Rineau wrote:
I have a container whose entrypoint uses 'su' to drop its privileges. The run of the container triggers an AVC, but the container seems to run normally.
That is on a server, and the SELinux Troubleshooter sends me emails (see the attachment).
Two questions:
1/ Is there a way to report bugs to Bugzilla using the command line sealert tool (or another command line tool), like what we can do using the GUI?
2/ What should I do to fix that issue, if that is one?
I copy-paste here the AVC (the attached email have more information):
type=AVC msg=audit(1434542552.136:6332403): avc: denied { search } for pid=11266 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
type=SYSCALL msg=audit(1434542552.136:6332403): arch=x86_64 syscall=keyctl success=no exit=EACCES a0=0 a1=fffffffd a2=0 a3=7f7c50a132f0 items=0 ppid=11065 pid=11266 auid=4294967295 uid=500 gid=501 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=su exe=/usr/bin/su subj=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 key=(null)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Le Wednesday 17 June 2015 17:46:16 Daniel J Walsh a écrit :
This is a leaked key from cron into the container. I have no idea how the crond keyring got into the container. Did you somehow restart docker via crond?
I do not understand how crond_t got involved.
In short: Last time my docker was restarted, it was by a downgrade from docker-1.6.2 to docker-1.5.0, using yum.
Now the long story to show proofs...
$ sudo yum history info [...] Begin time : Wed Jun 17 09:45:49 2015 [...] Downgrade docker-1.5.0-28.el7.centos.x86_64 @extras Downgraded 1.6.2-12.el7.x86_64 @/docker-1.6.2-12.el7.x86_64 Downgrade docker-selinux-1.6.0-11.0.1.el7.centos.x86_64 @extras Downgraded 1.6.2-12.el7.x86_64 @/docker-selinux-1.6.2-12.el7.x86_64 [...]
Here is the systemctl status for docker, to verify the last restart date:
$ sudo systemctl status docker docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled) Active: active (running) since Wed 2015-06-17 09:46:06 CEST; 23h ago
Then I use journalctl with that start date:
$ sudo journalctl --since '2015-06-17 09:46:05' -- Logs begin at Tue 2015-05-26 19:25:40 CEST, end at Thu 2015-06-18 09:07:58 CEST. -- Jun 17 09:46:05 cgal.geometryfactory.com yum[30475]: Installed: docker-1.5.0-28.el7.centos.x86_64 [... lines about sshd ...] Jun 17 09:46:05 cgal.geometryfactory.com systemd[1]: Reloading. Jun 17 09:46:05 cgal.geometryfactory.com systemd[1]: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket' Jun 17 09:46:05 cgal.geometryfactory.com systemd[1]: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket' Jun 17 09:46:05 cgal.geometryfactory.com systemd[1]: Stopping Docker Application Container Engine... Jun 17 09:46:05 cgal.geometryfactory.com docker[22851]: time="2015-06-17T09:46:05+02:00" level=info msg="Received signal 'terminated', starting shutdown of docker..." Jun 17 09:46:05 cgal.geometryfactory.com docker[22851]: time="2015-06-17T09:46:05+02:00" level=info msg="-job serveapi(unix:///var/run/docker.sock) = OK (0)" Jun 17 09:46:05 cgal.geometryfactory.com kernel: device-mapper: ioctl: unable to remove open device docker-253:6-25952279-pool Jun 17 09:46:05 cgal.geometryfactory.com systemd[1]: Starting Docker Application Container Engine... Jun 17 09:46:05 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:05+02:00" level="info" msg="+job serveapi(unix:///var/run/docker.sock)" Jun 17 09:46:05 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:05+02:00" level="info" msg="Listening for HTTP on unix (/var/run/docker.sock)" Jun 17 09:46:05 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:05+02:00" level="info" msg="+job init_networkdriver()" Jun 17 09:46:05 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:05+02:00" level="info" msg="-job init_networkdriver() = OK (0)" Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:06+02:00" level="info" msg="Loading containers: start." Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: ..........time="2015-06-17T09:46:06+02:00" level="error" msg="Failed to load container 878c1f82b6d78cf5dea18cbfefbe153d5169a30ed40c2cc5d0f6f1559841a3d1: open /var/lib/docker/containers/878c1f82b6d78cf5dea18cbfefbe153d5169a30ed4 Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: ................. Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:06+02:00" level="info" msg="Loading containers: done." Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:06+02:00" level="info" msg="docker daemon: 1.5.0-dev fc0329b/1.5.0; execdriver: native-0.2; graphdriver: devicemapper" Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:06+02:00" level="info" msg="+job acceptconnections()" Jun 17 09:46:06 cgal.geometryfactory.com docker[983]: time="2015-06-17T09:46:06+02:00" level="info" msg="-job acceptconnections() = OK (0)" Jun 17 09:46:06 cgal.geometryfactory.com systemd[1]: Started Docker Application Container Engine.
(The "[...]" correspond to a few lines from my sshd, that is regularly scanned and tried by hackers.)
Here is the relevant rpm script from docker-1.5.0-28:
postuninstall scriptlet (using /bin/sh):
/usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : if [ $1 -ge 1 ] ; then # Package upgrade, not uninstall /usr/bin/systemctl try-restart docker.service >/dev/null 2>&1 || : fi
I find nothing in my logs of cron or at that is about docker.
Could it be something in the container? Its entrypoint is rather simple: - create a user and a group, - then use /bin/su to drop privileges
I have the impression that I give to much information. I am sorry. Here is the code of the entrypoint, in case it might be relevant:
#!/bin/bash # This script is the entrypoint of a CGAL testsuite docker container. set -e
testresult_owner_uid=$(stat -c '%u' /mnt/testresults) testresult_group_id=$(stat -c '%g' /mnt/testresults)
# Only add cgal_tester group and user, when they do not already exist. groupadd -o -g $testresult_group_id -f cgal_tester id -u cgal_tester &>/dev/null || useradd -o -u $testresult_owner_uid -d /home/cgal_tester -g cgal_tester cgal_tester # useradd will not create the home directory and we cannot use # adduser, because it is Debian specific mkdir -p /home/cgal_tester chown cgal_tester:cgal_tester /home/cgal_tester
cd /home/cgal_tester su cgal_tester -c '/bin/bash /mnt/testsuite/run-testsuite.sh'
On 06/17/2015 08:46 AM, Laurent Rineau wrote:
I have a container whose entrypoint uses 'su' to drop its privileges. The run of the container triggers an AVC, but the container seems to run normally.
That is on a server, and the SELinux Troubleshooter sends me emails (see the attachment).> Two questions: 1/ Is there a way to report bugs to Bugzilla using the command line sealert tool (or another command line tool), like what we can do using the GUI?
2/ What should I do to fix that issue, if that is one?
I copy-paste here the AVC (the attached email have more information):
type=AVC msg=audit(1434542552.136:6332403): avc: denied { search } for pid=11266 comm="su" scontext=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 tcontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tclass=key
type=SYSCALL msg=audit(1434542552.136:6332403): arch=x86_64 syscall=keyctl success=no exit=EACCES a0=0 a1=fffffffd a2=0 a3=7f7c50a132f0 items=0 ppid=11065 pid=11266 auid=4294967295 uid=500 gid=501 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=su exe=/usr/bin/su subj=system_u:system_r:svirt_lxc_net_t:s0:c68,c965 key=(null)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Le Thursday 18 June 2015 09:50:18 Laurent Rineau a écrit :
Le Wednesday 17 June 2015 17:46:16 Daniel J Walsh a écrit :
This is a leaked key from cron into the container. I have no idea how the crond keyring got into the container. Did you somehow restart docker via crond?
I do not understand how crond_t got involved.
I am able to reproduce it on two different machines (Fedora 20 and CentOS 7, both x86_64), with:
docker run --rm fedora bash -x -c 'useradd -u 1000 -d /home/toto toto; su toto -c "date"'
What is really strange is that the "1000" has to be the id of a user that is logged on the machine (who we can see in `who`). I have tried to run that command with different users: root, me (500 or 1000), and two other users (1003 and 1005), using different user ids in the command. That is reproducible.
So, even if docker enforce a separation of namespace for user ids, there must be side effects. I imagine that those "keys" are related to user sessions, and that the Linux kernel leaks those keys between cgroups.
The CentOS machine uses: docker-1.5.0-28.el7.centos.x86_64 docker-selinux-1.6.0-11.0.1.el7.centos.x86_64
The Fedora machine uses: docker-io-1.5.0-1.fc20.x86_64 selinux-policy-targeted-3.12.1-197.fc20.noarch
I hope it can help...
On 06/18/2015 05:54 AM, Laurent Rineau wrote:
Le Thursday 18 June 2015 09:50:18 Laurent Rineau a écrit :
Le Wednesday 17 June 2015 17:46:16 Daniel J Walsh a écrit :
This is a leaked key from cron into the container. I have no idea how the crond keyring got into the container. Did you somehow restart docker via crond?
I do not understand how crond_t got involved.
I am able to reproduce it on two different machines (Fedora 20 and CentOS 7, both x86_64), with:
docker run --rm fedora bash -x -c 'useradd -u 1000 -d /home/toto toto; su toto -c "date"'
What is really strange is that the "1000" has to be the id of a user that is logged on the machine (who we can see in `who`). I have tried to run that command with different users: root, me (500 or 1000), and two other users (1003 and 1005), using different user ids in the command. That is reproducible.
So, even if docker enforce a separation of namespace for user ids, there must be side effects. I imagine that those "keys" are related to user sessions, and that the Linux kernel leaks those keys between cgroups.
The CentOS machine uses: docker-1.5.0-28.el7.centos.x86_64 docker-selinux-1.6.0-11.0.1.el7.centos.x86_64
The Fedora machine uses: docker-io-1.5.0-1.fc20.x86_64 selinux-policy-targeted-3.12.1-197.fc20.noarch
I hope it can help...
Actually this is a known problem with kernel keyrings not being namespace aware. Since the crond process created the keyring, root processes within the container are trying to use it and SELinux is blocking the access. We should probably just don'taudit access to the kernel keyring until we can get a keyring that works with namespaces.
Le Thursday 18 June 2015 08:41:51 Daniel J Walsh a écrit :
Actually this is a known problem with kernel keyrings not being namespace aware. Since the crond process created the keyring, root processes within the container are trying to use it and SELinux is blocking the access. We should probably just don'taudit access to the kernel keyring until we can get a keyring that works with namespaces.
Should I fill a bug report, or will you deal with this yourself?
On 06/18/2015 09:15 AM, Laurent Rineau wrote:
Le Thursday 18 June 2015 08:41:51 Daniel J Walsh a écrit :
Actually this is a known problem with kernel keyrings not being namespace aware. Since the crond process created the keyring, root processes within the container are trying to use it and SELinux is blocking the access. We should probably just don'taudit access to the kernel keyring until we can get a keyring that works with namespaces.
Should I fill a bug report, or will you deal with this yourself?
Bug has been filed for a while, but little action on it.
http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t...
Le Wednesday 17 June 2015 14:46:28 Laurent Rineau a écrit :
I have a container whose entrypoint uses 'su' to drop its privileges. The run of the container triggers an AVC, but the container seems to run normally.
That is on a server, and the SELinux Troubleshooter sends me emails (see the attachment).
Two questions:
1/ Is there a way to report bugs to Bugzilla using the command line sealert tool (or another command line tool), like what we can do using the GUI?
2/ What should I do to fix that issue, if that is one?
Dear mailing list,
I got answers, and even a fix for the second question. What about the first one? The SELinux Troubleshoot daemon sends me email when there is an AVC. Is there a way to check if the AVC is already reported to Bugzilla, and maybe report it, the same way the GUI of sealert does?
I cannot use the GUI of sealert, as least not easily, because the AVC was triggered on a remove server, handled by ssh.
selinux@lists.fedoraproject.org