Bug 1261236

Summary: SELinux is preventing iptables from read, write access on the file /run/ffivJ8nEb (deleted).
Product: [Fedora] Fedora Reporter: Richard Jasmin <spike85051>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: dominick.grift, dwalsh, jpopelka, lvrabec, martin, mgrepl, plautrba, spike85051, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:4590795b996cf16369363bcb7fc2a79e12e7732f1de9e993b47ef1f690854e66
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 17:50:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard Jasmin 2015-09-09 01:31:18 UTC
Description of problem:
woke machine up
SELinux is preventing iptables from read, write access on the file /run/ffivJ8nEb (deleted).

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

If you want to fix the label. 
/run/ffivJ8nEb (deleted) default label should be var_run_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /run/ffivJ8nEb (deleted)

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

If you believe that iptables should be allowed read write access on the ffivJ8nEb (deleted) 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:
# grep iptables /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:iptables_t:s0
Target Context                system_u:object_r:firewalld_var_run_t:s0
Target Objects                /run/ffivJ8nEb (deleted) [ file ]
Source                        iptables
Source Path                   iptables
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.12.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.1.6-200.fc22.x86_64 #1 SMP Mon
                              Aug 17 19:54:31 UTC 2015 x86_64 x86_64
Alert Count                   29
First Seen                    2015-09-08 20:24:41 CDT
Last Seen                     2015-09-08 20:24:41 CDT
Local ID                      0822342b-a7ae-47b8-a6c0-407afa54cf95

Raw Audit Messages
type=AVC msg=audit(1441761881.728:532): avc:  denied  { read write } for  pid=1413 comm="iptables" path=2F72756E2F666669764A386E4562202864656C6574656429 dev="tmpfs" ino=24018 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:firewalld_var_run_t:s0 tclass=file permissive=0


Hash: iptables,iptables_t,firewalld_var_run_t,file,read,write

Version-Release number of selected component:
selinux-policy-3.13.1-128.12.fc22.noarch

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.6-200.fc22.x86_64
type:           libreport

Potential duplicate: bug 892045

Comment 1 Richard Jasmin 2015-09-11 04:16:15 UTC
has to do when network settings are established or reset.If you reset them in the UI, this happens again. The questions is why are we accessing a deleted file and/or why is this an issue?Maybe we are creating this condition when resetting the network settings and not waiting for iptables to do its bidding.

Comment 2 Miroslav Grepl 2015-09-21 07:58:54 UTC
It looks like a leak.

Comment 3 Martin Stefany 2016-02-29 15:17:43 UTC
From what I see in the logs, this is happening also in CentOS7, so also in RHEL7.

Comment 4 Thomas Woerner 2016-06-13 11:53:48 UTC
Which firwalld version is used here?

Up to version 0.4.1 firewalld was not using any files in /run. Therefore this seems to be a leak from something else. Are you able to hunt this down to see where it comes from?

Comment 5 Martin Stefany 2016-06-13 12:42:12 UTC
In my case:

# rpm -qi firewalld
Name        : firewalld
Version     : 0.3.9
Release     : 14.el7
Architecture: noarch
...

So I get:

# grep AVC audit.log | grep firewalld | audit2allow


#============= firewalld_t ==============

#!!!! This avc can be allowed using the boolean 'daemons_dump_core'
allow firewalld_t root_t:dir write;

#============= iptables_t ==============
allow iptables_t firewalld_var_run_t:file { read write };

Comment 6 Thomas Woerner 2016-06-13 13:14:45 UTC
(In reply to Martin Stefany from comment #5)
> In my case:
> 
> # rpm -qi firewalld
> Name        : firewalld
> Version     : 0.3.9
> Release     : 14.el7
> Architecture: noarch
> ...
> 
> So I get:
> 
> # grep AVC audit.log | grep firewalld | audit2allow
> 
> 
> #============= firewalld_t ==============
> 
> #!!!! This avc can be allowed using the boolean 'daemons_dump_core'
> allow firewalld_t root_t:dir write;
> 
> #============= iptables_t ==============
> allow iptables_t firewalld_var_run_t:file { read write };

It seems that python is dying on your machine. Do you have a special configuration that is resulting in this?

It is a different issue than the above. Please open a new bug for this.

Comment 7 Fedora End Of Life 2016-07-19 17:50:03 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 8 Red Hat Bugzilla 2023-09-14 03:05:03 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days