+++ This bug was initially created as a clone of Bug #1658815 +++ Description of problem: Similar to : See same error as : https://bugzilla.redhat.com/show_bug.cgi?id=1652035 https://bugzilla.redhat.com/show_bug.cgi?id=1638547 fixed in: openstack-selinux-0.8.15-1.el7ost ###customer has : openstack-selinux-0.8.15-1.el7ost.noarch Thu Dec 6 08:15:00 2018 Customer has https://access.redhat.com/errata/RHBA-2018:3664 for https://bugzilla.redhat.com/show_bug.cgi?id=1645270 , but https://bugzilla.redhat.com/show_bug.cgi?id=1640528 which has fixed in version: selinux- policy-3.13.1-229.el7_6.6 , is not released ? grep denied /var/log/audit/audit.log |grep nova type=AVC msg=audit(1544557830.595:1357): avc: denied { write } for pid=10185 comm="sudo" name=".lsassd" dev="dm-3" ino=262401 scontext=system_u:system_r:nova_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1544557830.595:1358): avc: denied { write } for pid=10185 comm="sudo" name=".lsassd" dev="dm-3" ino=262401 scontext=system_u:system_r:nova_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=sock_file permissive=0 ... tail /var/log/nova/nova-api.log 2018-12-11 12:50:39.283 10419 ERROR nova Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iptables-save -c 2018-12-11 12:50:39.283 10419 ERROR nova Exit code: 1 2018-12-11 12:50:39.283 10419 ERROR nova Stdout: u'' 2018-12-11 12:50:39.283 10419 ERROR nova Stderr: u'sudo: PAM account management error: Error in service module\n' 2018-12-11 12:50:39.283 10419 ERROR nova Version-Release number of selected component (if applicable): installed-rpms container-selinux-2.73-2.el7.noarch Thu Dec 6 08:14:28 2018 libselinux-2.5-14.1.el7.i686 Thu Dec 6 08:16:13 2018 libselinux-2.5-14.1.el7.x86_64 Thu Dec 6 08:11:59 2018 libselinux-devel-2.5-14.1.el7.x86_64 Thu Dec 6 08:12:23 2018 libselinux-python-2.5-14.1.el7.x86_64 Thu Dec 6 08:12:12 2018 libselinux-ruby-2.5-14.1.el7.x86_64 Thu Dec 6 08:16:07 2018 libselinux-utils-2.5-14.1.el7.x86_64 Thu Dec 6 08:12:09 2018 openstack-selinux-0.8.15-1.el7ost.noarch Thu Dec 6 08:15:00 2018 selinux-policy-3.13.1-229.el7_6.6.noarch Tue Dec 11 10:17:45 2018 selinux-policy-devel-3.13.1-229.el7_6.6.noarch Tue Dec 11 10:17:57 2018 selinux-policy-targeted-3.13.1-229.el7_6.6.noarch Tue Dec 11 10:18:12 2018 How reproducible: 100% Steps to Reproduce: 1. enable selinux enforcing ; try to start nova-api 2. 3. Actual results: fails with ERROR nova Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iptables-save -c 2018-12-11 12:50:39.283 10419 ERROR nova Exit code: 1 Expected results: works Additional info: works with setenforce 0; the command sudo nova-rootwrap /etc/nova/rootwrap.conf iptables-save -c works via cli, but not from nova. Note: customer has fix for the bz's listed above where the same problem is identified. Need to see why the fix isn't working here.. --- Additional comment from Zoli Caplovic on 2019-01-15 16:47:11 UTC --- Checking the status of the BZ #1640528 https://bugzilla.redhat.com/show_bug.cgi?id=1640528 which seems to address the same problem. --- Additional comment from Zoli Caplovic on 2019-01-17 16:01:44 UTC --- Jeremy, there is related bug 1640528 (https://bugzilla.redhat.com/show_bug.cgi?id=1640528). The fix for the issue should be included in the next 7.6 update. Could you try to verify it (as soon as the update will be released) and let me know about the result, please? Thank you Zoli Caplovic --- Additional comment from Jeremy on 2019-01-17 16:28:35 UTC --- Yes, As soon as 1640528 is released I will have the customer update and test. --- Additional comment from Jeremy on 2019-01-31 18:55:12 UTC --- Zoil, We just realized that bug 1640528 is for rhel7.7, but the fix is already available , because erratum with BZ#1645270 is already out. The customer has even already tried the fix for 1645270 a while ago with selinux-policy-3.13.1-229.el7_6.6 and it did not help. So it seems there is some other problem. Any thoughts? --- Additional comment from Milos Malik on 2019-03-04 16:54:39 UTC --- It seems that /var/lib/pbis/.lsassd socket is labeled incorrectly, even if the customer applied the fcontext change via semanage and executed 'restorecon -Rv ...' Possible cause is that /var/lib/pbis/.lsassd socket got removed. Because we don't know which process creates the .lsassd socket, we cannot run 'restorecon -Rv ...' everytime the socket gets created. What can we do? We can use the restorecon daemon. The restorecond service makes sure that all locations written in the /etc/selinux/restorecond.conf file are labeled correctly. # yum -y install /usr/sbin/restorecond # echo '/var/lib/pbis/*' >> /etc/selinux/restorecond.conf # systemctl enable restorecond # systemctl start restorecond Now, the /var/lib/pbis/.lsassd socket will get a correct label as soon as it gets created. --- Additional comment from Julie Pichon on 2019-03-05 16:45:27 UTC --- Thank you for trying this out! This is similar to the solution we are working toward. What would be ideal is if the pbis-open selinux policy upstream could be updated to include these two requires + pbis_client calls you added. nova_t and neutron_t are defined in selinux-policy upstream so the pbis policy could reference the types directly, with no extra dependency. Here are the possible solutions: (1) Update pbis-open to include the pbis_client() calls for both nova_t and neutron_t This is in my opinion the cleanest solution. It would just work. (2) Add a boolean to openstack-selinux to optionally support pbis Downside: pbis_client() does not exist in selinux-policy upstream, and we can't add a dependency to the pbis-open package. This means we will have to copy the current interface as is into openstack-selinux and may miss future changes. This boolean will be disabled by default so we'll need to document it as well, and the customer will need to enable it themselves. (Suggested in comment 31) Upside: Easier from the customer perspective than (3), just a boolean to manage (3) Customer to update pbis.te manually as described in comment 32 Downside: The change must be repeated and module recompiled with every pbis-open update. --- Additional comment from Julie Pichon on 2019-03-06 09:07:12 UTC --- Actually about (3), it should be possible instead for the customer to create a separate .te file they can maintain separately (so no risk of overwriting) with these 4 lines (and then compile it manually + load it with semodule -i). They have the pbis-open rules on their system so they should be able to call the pbis_client() interface from any other file. The downside would be if there is a name change to the interface down the line.