doing docker build, "SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.", kills wireless
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
i grabbed a few hundred lines of "journalctl" output that show all sorts of evil nonsense happening with networking, but it would appear that i'm not the only one seeing this issue:
https://bugzilla.redhat.com/buglist.cgi?quicksearch=selinux%20preventing%20a...
so it's not clear whether there's a bugzilla here or not -- i get the feeling top men are already on this. top men.
rday
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
On 08/19/2015 07:36 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
Something is crashing though which is causing the AVC
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
Something is crashing though which is causing the AVC
as in, enabled and not just permissive?
rday
On 08/19/2015 08:03 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
Something is crashing though which is causing the AVC
as in, enabled and not just permissive?
rday
Either way.
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 07:36 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
no difference ... i edited /etc/selinux/config, set SELINUX=enforcing, rebooted and let my system chug away relabelling, came back up, tested again ... same result.
rday
On 08/19/2015 08:41 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 07:36 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
by now, i'm getting *really* good at debugging. was doing a simple docker build (docker-1.8.1) with first few lines of Dockerfile (which worked fine not that long ago):
FROM ubuntu:14.04 MAINTAINER Robert P. J. Day ENV REFRESHED_AT 2015-08-18
RUN apt-get -y -q update && apt-get -y -q install nginx ... snip ...
and it was *entirely* reproducible that the instant docker started to process that "RUN apt-get" command, the wireless connection on my Fedora 22 laptop was blown away. grabbed this from SELinux:
===== start =====
SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the sigchld access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that abrt-hook-ccpp should be allowed sigchld access on processes labeled kernel_t 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: # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:system_r:kernel_t:s0 Target Objects Unknown [ process ] Source abrt-hook-ccpp Source Path /usr/libexec/abrt-hook-ccpp Port <Unknown> Host localhost.localdomain Source RPM Packages abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name localhost.localdomain Platform Linux localhost.localdomain 4.1.5-200.fc22.x86_64 #1 SMP Mon Aug 10 23:38:23 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-08-18 12:57:36 EDT Last Seen 2015-08-18 12:57:36 EDT Local ID 523c8bed-7428-49e7-b301-3a932852b135
Raw Audit Messages type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4 success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld
===== end =====
followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
no difference ... i edited /etc/selinux/config, set SELINUX=enforcing, rebooted and let my system chug away relabelling, came back up, tested again ... same result.
While I have seen both AVCs and actual blocks from selinux in permissive mode in the past (and specifically on network stuff), if you've disabled selinux on the host machine I don't see how it could generate an AVC at all.
Are you certain the AVC isn't coming from the dockerized OS itself? I could see the AVC being generated on the docker and getting reflected back to the host somehow (I suspect critical messages from the dockers get piped through so you're aware of them, but that's a wild guess). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - grep me no patterns and I'll tell you no lines - ----------------------------------------------------------------------
On Wed, 19 Aug 2015, Rick Stevens wrote:
On 08/19/2015 08:41 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 07:36 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote:
On Tue, 18 Aug 2015, Robert P. J. Day wrote:
> by now, i'm getting *really* good at debugging. was doing a simple > docker build (docker-1.8.1) with first few lines of Dockerfile (which > worked fine not that long ago): > > FROM ubuntu:14.04 > MAINTAINER Robert P. J. Day > ENV REFRESHED_AT 2015-08-18 > > RUN apt-get -y -q update && apt-get -y -q install nginx > ... snip ... > > and it was *entirely* reproducible that the instant docker started to > process that "RUN apt-get" command, the wireless connection on my > Fedora 22 laptop was blown away. grabbed this from SELinux: > > ===== start ===== > > SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the
sigchld access on a process.
> > ***** Plugin catchall (100. confidence) suggests
> > If you believe that abrt-hook-ccpp should be allowed sigchld access on
processes labeled kernel_t 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: > # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol > # semodule -i mypol.pp > > Additional Information: > Source Context system_u:system_r:NetworkManager_t:s0 > Target Context system_u:system_r:kernel_t:s0 > Target Objects Unknown [ process ] > Source abrt-hook-ccpp > Source Path /usr/libexec/abrt-hook-ccpp > Port <Unknown> > Host localhost.localdomain > Source RPM Packages
abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64
> Target RPM Packages > Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch > Selinux Enabled True > Policy Type targeted > Enforcing Mode Permissive > Host Name localhost.localdomain > Platform Linux localhost.localdomain
4.1.5-200.fc22.x86_64
> #1 SMP Mon Aug 10 23:38:23 UTC 2015
x86_64 x86_64
> Alert Count 1 > First Seen 2015-08-18 12:57:36 EDT > Last Seen 2015-08-18 12:57:36 EDT > Local ID 523c8bed-7428-49e7-b301-3a932852b135 > > Raw Audit Messages > type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for
pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
> > > type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4
success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
> > Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld > > ===== end ===== followup to the above ... i ran the suggested selinux-related commands, but that had no apparent effect, so i'm still stuck. for people who know docker, you'll recognize that the error occurred at the first instruction in the Dockerfile that requires network access, the "RUN apt-get ..." command (i already have the ubuntu base image on my system).
i grabbed a few hundred lines from "journalctl" and stuck them here: http://pastebin.com/KzrYMFvC. you can see the very first command there is the docker invocation:
Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker build -t jamtur01/nginx .
thoughts? is it bugzilla time?
rday
Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
no difference ... i edited /etc/selinux/config, set SELINUX=enforcing, rebooted and let my system chug away relabelling, came back up, tested again ... same result.
While I have seen both AVCs and actual blocks from selinux in permissive mode in the past (and specifically on network stuff), if you've disabled selinux on the host machine I don't see how it could generate an AVC at all.
Are you certain the AVC isn't coming from the dockerized OS itself? I could see the AVC being generated on the docker and getting reflected back to the host somehow (I suspect critical messages from the dockers get piped through so you're aware of them, but that's a wild guess).
i have no doubt that the container OS is the *ultimate* source of the problem, but that in no way explains how it can reach out from the container and blow away the wireless connection on the host. that's what leaves me baffled.
rday
You have a bad label on /etc/resolv.conf.
restorecon -v /etc/resolv.conf
I have no idea how this is getting mislabeled. Are you doing anything special with /etc/resolv.conf?
Also turn on the cups_execmem boolean
setsebool -P cups_execmem 1
On 08/19/2015 10:10 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Rick Stevens wrote:
On 08/19/2015 08:41 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 07:36 AM, Robert P. J. Day wrote:
On Wed, 19 Aug 2015, Daniel J Walsh wrote:
On 08/19/2015 02:43 AM, Robert P. J. Day wrote: > On Tue, 18 Aug 2015, Robert P. J. Day wrote: > >> by now, i'm getting *really* good at debugging. was doing a simple >> docker build (docker-1.8.1) with first few lines of Dockerfile (which >> worked fine not that long ago): >> >> FROM ubuntu:14.04 >> MAINTAINER Robert P. J. Day >> ENV REFRESHED_AT 2015-08-18 >> >> RUN apt-get -y -q update && apt-get -y -q install nginx >> ... snip ... >> >> and it was *entirely* reproducible that the instant docker started to >> process that "RUN apt-get" command, the wireless connection on my >> Fedora 22 laptop was blown away. grabbed this from SELinux: >> >> ===== start ===== >> >> SELinux is preventing /usr/libexec/abrt-hook-ccpp from using the
sigchld access on a process.
>> ***** Plugin catchall (100. confidence) suggests
>> If you believe that abrt-hook-ccpp should be allowed sigchld access on
processes labeled kernel_t 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: >> # grep abrt-hook-ccpp /var/log/audit/audit.log | audit2allow -M mypol >> # semodule -i mypol.pp >> >> Additional Information: >> Source Context system_u:system_r:NetworkManager_t:s0 >> Target Context system_u:system_r:kernel_t:s0 >> Target Objects Unknown [ process ] >> Source abrt-hook-ccpp >> Source Path /usr/libexec/abrt-hook-ccpp >> Port <Unknown> >> Host localhost.localdomain >> Source RPM Packages
abrt-addon-coredump-helper-2.6.1-2.fc22.x86_64
>> Target RPM Packages >> Policy RPM selinux-policy-3.13.1-128.10.fc22.noarch >> Selinux Enabled True >> Policy Type targeted >> Enforcing Mode Permissive >> Host Name localhost.localdomain >> Platform Linux localhost.localdomain
4.1.5-200.fc22.x86_64
>> #1 SMP Mon Aug 10 23:38:23 UTC 2015
x86_64 x86_64
>> Alert Count 1 >> First Seen 2015-08-18 12:57:36 EDT >> Last Seen 2015-08-18 12:57:36 EDT >> Local ID 523c8bed-7428-49e7-b301-3a932852b135 >> >> Raw Audit Messages >> type=AVC msg=audit(1439917056.327:640): avc: denied { sigchld } for
pid=4555 comm="abrt-hook-ccpp" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
>> >> type=SYSCALL msg=audit(1439917056.327:640): arch=x86_64 syscall=wait4
success=yes exit=1273 a0=4f9 a1=7fffdb95f19c a2=0 a3=0 items=0 ppid=131 pid=4555 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=abrt-hook-ccpp exe=/usr/libexec/abrt-hook-ccpp subj=system_u:system_r:kernel_t:s0 key=(null)
>> Hash: abrt-hook-ccpp,NetworkManager_t,kernel_t,process,sigchld >> >> ===== end ===== > followup to the above ... i ran the suggested selinux-related > commands, but that had no apparent effect, so i'm still stuck. for > people who know docker, you'll recognize that the error occurred at > the first instruction in the Dockerfile that requires network access, > the "RUN apt-get ..." command (i already have the ubuntu base image on > my system). > > i grabbed a few hundred lines from "journalctl" and stuck them here: > http://pastebin.com/KzrYMFvC. you can see the very first command there > is the docker invocation: > > Aug 19 05:24:35 localhost.localdomain sudo[4190]: rpjday : TTY=pts/0 > ; PWD=/home/rpjday/docker/TDB/sample ; USER=root ; COMMAND=/bin/docker > build -t jamtur01/nginx . > > thoughts? is it bugzilla time? > > rday > Yes open a bugzilla, although this is a very strange AVC. It basically shows abrt-hook-ccpp executing under networkmanager domain and sending sigchld to kernel_t.
Why would networkmanager execed processes be sending a sigchld to a kernel process?
beats me, this is way outside my comfort zone. by the way, even though selinux was in permissive mode, i thought i'd play it safe and just disable it entirely, so i did, rebooted, "sestatus" clearly shows selinux disabled, but i got the same error.
i'll do it one more time shortly just to make sure it's not some intermittent weirdness, then i'll BZ it. open to suggestions as to anything else i might try, or add to the BZ submission.
rday
With SELinux disabled you should not be getting any AVC's
If you turn SELInux back on and do a full relabel, I think the problem will go away.
no difference ... i edited /etc/selinux/config, set SELINUX=enforcing, rebooted and let my system chug away relabelling, came back up, tested again ... same result.
While I have seen both AVCs and actual blocks from selinux in permissive mode in the past (and specifically on network stuff), if you've disabled selinux on the host machine I don't see how it could generate an AVC at all.
Are you certain the AVC isn't coming from the dockerized OS itself? I could see the AVC being generated on the docker and getting reflected back to the host somehow (I suspect critical messages from the dockers get piped through so you're aware of them, but that's a wild guess).
i have no doubt that the container OS is the *ultimate* source of the problem, but that in no way explains how it can reach out from the container and blow away the wireless connection on the host. that's what leaves me baffled.
rday
-
Daniel J Walsh -
Rick Stevens -
Robert P. J. Day