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
>
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
