Bug 602464 - SELinux is preventing /usr/sbin/libvirtd "rename" access on iptables.augnew.
Summary: SELinux is preventing /usr/sbin/libvirtd "rename" access on iptables.aug...
Status: CLOSED DUPLICATE of bug 621499
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: netcf   
(Show other bugs)
Version: 6.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: qe-baseos-daemons
Whiteboard: setroubleshoot_trace_hash:6722066b69a...
Depends On:
Blocks: Rhel6.0LibvirtTier2
TreeView+ depends on / blocked
Reported: 2010-06-09 21:45 UTC by Matěj Cepl
Modified: 2010-08-06 18:44 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-06 18:44:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matěj Cepl 2010-06-09 21:45:41 UTC

SELinux is preventing /usr/sbin/libvirtd "rename" access on iptables.augnew.

Podrobný popis:

[SELinux je v tolerantním režimu. Přístup byl povolen.]

SELinux denied access requested by libvirtd. It is not expected that this access
is required by libvirtd and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug

Další informace:

Kontext zdroje                system_u:system_r:virtd_t:s0-s0:c0.c1023
Kontext cíle                 staff_u:object_r:etc_runtime_t:s0
Objekty cíle                 iptables.augnew [ file ]
Zdroj                         libvirtd
Cesta zdroje                  /usr/sbin/libvirtd
Port                          <Neznámé>
Počítač                    (removed)
RPM balíčky zdroje          libvirt-0.8.1-7.el6
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.7.19-23.el6
Selinux povolen               True
Typ politiky                  targeted
Vynucovací režim            Permissive
Název zásuvného modulu     catchall
Název počítače            (removed)
Platforma                     Linux (removed) 2.6.32-33.el6.x86_64 #1
                              SMP Thu Jun 3 13:00:03 EDT 2010 x86_64 x86_64
Počet upozornění           2
Poprvé viděno               St 9. červen 2010, 23:41:55 CEST
Naposledy viděno             St 9. červen 2010, 23:41:55 CEST
Místní ID                   7384825e-986d-46a2-91bd-6da695672d94
Čísla řádků              

Původní zprávy auditu      

node=(removed) type=AVC msg=audit(1276119715.745:30): avc:  denied  { rename } for  pid=1845 comm="libvirtd" name="iptables.augnew" dev=dm-1 ino=130672 scontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:etc_runtime_t:s0 tclass=file

node=(removed) type=AVC msg=audit(1276119715.745:30): avc:  denied  { unlink } for  pid=1845 comm="libvirtd" name="iptables" dev=dm-1 ino=130705 scontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:etc_runtime_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1276119715.745:30): arch=c000003e syscall=82 success=yes exit=0 a0=2b4fac0 a1=347d580 a2=7ffffaf25d30 a3=22 items=0 ppid=1 pid=1845 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  catchall,libvirtd,virtd_t,etc_runtime_t,file,rename
audit2allow suggests:

#============= virtd_t ==============
allow virtd_t etc_runtime_t:file { rename unlink };

Comment 2 RHEL Product and Program Management 2010-06-09 22:12:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Daniel Walsh 2010-06-10 12:28:22 UTC
What process creates iptables.augnew  Looks like the process that is creating iptables is in an init script?

Comment 4 Daniel Walsh 2010-06-10 12:28:59 UTC
Or it is a program that does not have SELinux rules written for it.

ps -eZ | grep initrc_t

Comment 5 Matěj Cepl 2010-06-10 14:05:06 UTC
johanka:~$ ps -eZ | grep initrc_t

Comment 6 Bill Nottingham 2010-06-10 16:16:14 UTC
The assumption is that .augnew comes from augeas somehow.

Comment 7 Matěj Cepl 2010-06-10 20:22:30 UTC
(In reply to comment #6)
> The assumption is that .augnew comes from augeas somehow.    


johanka:~$ rpm -qa \*aug\*

I didn't even knew I have such thing on my computer.

Comment 8 Laine Stump 2010-06-16 09:49:14 UTC
It's the netcf library that is calling augeas and causing it to create that file, and that is something valid.

I thought these were all fixed and working? (I even recall (or did I imagine it?) having a discussion about the .augnew files with lutter and dwalsh) Has there been a regression somehow?

Comment 9 Daniel Walsh 2010-06-16 14:54:58 UTC
I still think some other app created the file.  libvirt should have created it with a label of system_conf_t.

It looks like it was created by an init script and now libvirt is trying to replace it.

Files under /etc/sysconfig/iptables* should be labeled system_conf_t.

Comment 10 Daniel Walsh 2010-06-29 12:17:20 UTC
Daniel any ideas?

Comment 11 Daniel Berrange 2010-06-29 12:42:24 UTC
No particular ideas, but I have to question why netcf is changing the iptables rules at all.  IMHO it shouldn't be.

Comment 12 Laine Stump 2010-06-29 12:49:34 UTC
I'm unclear on the details (lutter can provide a better explanation), but when net.bridge.bridge-nf-call-iptables = 1, netcf adds in rules to let traffic pass across bridges.

Comment 13 Daniel Berrange 2010-06-29 12:57:09 UTC
IMHO that is a bug, because that is a policy decision for the app using netcf to decide upon, that is separate from the task of configuring a bridge. netcf shouldn't make such a policy decision itself, because admins may well actually want to have control over the filtering in such a case.

Comment 14 Daniel Walsh 2010-06-29 15:31:27 UTC
Reassigning to libvirt?

Comment 15 Laine Stump 2010-06-29 15:40:10 UTC
If you're basing that on Comment 13, I think we should hold the verdict until lutter has his say. (After that, if it's still appropriate to reassign, then it should go to netcf, not libvirt)

Comment 16 David Lutterkort 2010-06-30 02:25:44 UTC
(In reply to comment #13)
> IMHO that is a bug, because that is a policy decision for the app using netcf
> to decide upon, that is separate from the task of configuring a bridge. netcf
> shouldn't make such a policy decision itself, because admins may well actually
> want to have control over the filtering in such a case.    

Doesn't that just mimick what libvirt does for private network setups ? What behavior do you prefer ? We could split the iptables mangling into a separate netcf call, though that still wouldn't address the issue in this bug.

Comment 17 Daniel Berrange 2010-06-30 10:33:11 UTC
The libvirt virtual networking is addressing a specific use case, which is to provide a NAT based network. In that we add a bunch of iptables rules to apply NAT forwarding. This doesn't change /etc/ iptables config files at all, because lokkit doesn't play nicely with custom rules in its configs, so we just directly manage live iptables rules. 

Setting up a physical bridge is a general host configuration task. One of those use cases may be to attach guests to a physical interface. So we should not assume that the admin wants to bypass iptables filtering when configuring a bridge. The default sysctl is net.bridge.bridge-nf-call-iptables=0, so if the admin has changed this to '1', then they likely *want* traffic to be processed by iptables but now netcf has bypassed this. Basically, if the admin wants this bypass they can set it. When configuring bridges normally using ifcfg-XXX files, there is no change in iptables rules, so having netcf change iptables rules when asked for a bridge is not mirroring normal behaviour. I don't particularly see a need to make an explicit API call in netcf for setting up this iptables rule either, since this isn't anything todo with network interface management, it is a separate firewall policy decision.

Comment 18 Laine Stump 2010-07-13 16:23:06 UTC
I'm leaning toward Dan's point of view on this. Perhaps we should have a discussion to come to consensus?

Comment 20 Laine Stump 2010-08-06 18:44:44 UTC
There is another bug addressing the same issue: bug 621499

*** This bug has been marked as a duplicate of bug 621499 ***

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