Bug 1777738
| Summary: | Certmonger tries to call iptables and generate denials | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Cédric Jeanneret <cjeanner> |
| Component: | openstack-selinux | Assignee: | Julie Pichon <jpichon> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jeremy Agee <jagee> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 16.0 (Train) | CC: | alee, amoralej, ggrasza, jschluet, lbragsta, lhh, lvrabec, mburns, rmascena, zcaplovi |
| Target Milestone: | z2 | Keywords: | TestOnly, Triaged, ZStream |
| Target Release: | 16.0 (Train on RHEL 8.1) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-selinux-0.8.20-0.20191204122247.4b7dae8.el8ost | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-20 10:44:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hello Ade! Do you know anything about this certmonger/iptables thing? It's weird, it sounds like certmonger is calling podman (comm=podman) and it runs something with iptables... Any idea? Thanks! After applying the fix from bug 1777368, only one iptable denial remains: type=PROCTITLE msg=audit(11/29/2019 14:32:51.557:32236) : proctitle=/usr/sbin/iptables --version type=SYSCALL msg=audit(11/29/2019 14:32:51.557:32236) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xc420041ac0 a1=0xc4202be2c0 a2=0xc42030c2d0 a3=0x0 items=0 ppid=205530 pid=205548 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=iptables exe=/usr/sbin/xtables-multi subj=system_u:system_r:iptables_t:s0 key=(null) type=AVC msg=audit(11/29/2019 14:32:51.557:32236) : avc: denied { write } for pid=205548 comm=iptables path=pipe:[1864791] dev="pipefs" ino=1864791 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file permissive=1 iptables_t requiring a write permission over certmonger_t? The postsave_cmd that is used to replace certificates and reload the services can restart the container (using podman restart). I see that's the case for haproxy and qpid. This might trigger the iptables call. According to our records, this should be resolved by openstack-selinux-0.8.20-0.20200130230725.3fca012.el8ost. This build is available now. |
Description of problem: For some reasons, it seems certmonger is trying to call iptables (via podman ?!) and we get some AVCs. type=SYSCALL msg=audit(11/28/2019 08:35:40.569:5340) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=0xffffffffffffff9c a1=0xc420040620 a2=0xc4201e01d8 a3=0x0 items=0 ppid=26631 pid=26632 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=podman exe=/usr/bin/podman subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(11/28/2019 08:35:40.569:5340) : avc: denied { getattr } for pid=26632 comm=podman path=/usr/sbin/xtables-multi dev="sda1" ino=211829 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file permissive=1 type=PROCTITLE msg=audit(11/28/2019 08:35:40.570:5341) : proctitle=/usr/sbin/iptables --version type=SYSCALL msg=audit(11/28/2019 08:35:40.570:5341) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xc4200406e0 a1=0xc42000d3a0 a2=0xc420373860 a3=0x0 items=0 ppid=26632 pid=26648 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=iptables exe=/usr/sbin/xtables-multi subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(11/28/2019 08:35:40.570:5341) : avc: denied { execute_no_trans } for pid=26648 comm=podman path=/usr/sbin/xtables-multi dev="sda1" ino=211829 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(11/28/2019 08:35:40.570:5341) : avc: denied { read open } for pid=26648 comm=podman path=/usr/sbin/xtables-multi dev="sda1" ino=211829 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(11/28/2019 08:35:40.570:5341) : avc: denied { execute } for pid=26648 comm=podman name=xtables-multi dev="sda1" ino=211829 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file permissive=1 I just saw that while investigating TLS-everywhere with "local certmonger CA" as described here[1] I'm a bit surprised to find this kind of call. Not sure if we should allow it - we probably need some more info about certmonger whereabouts... [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/tls_everywhere.html#certmonger-based-public-and-internal-tls Version-Release number of selected component (if applicable): openstack-selinux-0.8.20-0.20191125094339.a4fcc2c.el7.noarch How reproducible: Always Steps to Reproduce: 1. Deploy an undercloud using TLS and local certmonger CA *in permissive* 2. Check audit.log 3. Actual results: We find some interesting AVCs... Expected results: We shouldn't find anything Additional info: Output is generated using `cat audit.log| ausearch -i | grep -B2 -A1 denied' and searching for iptables entries. This is happening *after* the deploy - so you might need to wait a bit before seeing it. For instance, it appeared something like 30 minutes after the deploy on my lab....