Zoli any update here?

Checking the status of the BZ #1640528 https://bugzilla.redhat.com/show_bug.cgi?id=1640528 which seems to address the same problem.

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

Yes, As soon as 1640528 is released I will have the customer update and test.

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?

Jeremy, 

I have discussed the issue with colleagues. To analyse it deeper we need the (relevant part of) audit.log with SELinux set to permissive. 


Thank you in advance

Zoli Caplovic

Based on SELinux policy rules, there is a label that allows programs running under nova_t to write a to a lsassd socket:

# sesearch -s nova_t -c sock_file -p write -A -C | grep lsassd
   allow nsswitch_domain lsassd_var_socket_t : sock_file { write getattr append open } ; 
#

Based on SELinux fcontexts patterns, the expected location of .lsassd sockets are:

# semanage fcontext -l | grep '\.lsassd'
/var/lib/likewise/\.lsassd                         socket             system_u:object_r:lsassd_var_socket_t:s0 
/var/lib/likewise-open/\.lsassd                    socket             system_u:object_r:lsassd_var_socket_t:s0 
#

I don't think that current SELinux policy defines a more specific label for /var/lib/pbis directory, but for the .lsassd socket inside that directory we can use the lsassd_var_socket_t label. My suggestion is to run following commands:

# semanage fcontext -a -t lsassd_var_socket_t '/var/lib/pbis/.lsassd'
# restorecon -Rv /var/lib/pbis

SELinux denials mentioned in comment#0 will disappear as a result of above-mentioned commands.

Many thanks for the helpful comment, Milos. It looks like the denials in audit.log are still present, and they still reference var_lib_t despite the relabelling. Would that kind of issue ring a bell?

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.

Thank you for the link to the powerbroker SELinux policies, that was instructive.

https://github.com/BeyondTrust/pbis-open/blob/master/config/linux/redhat/rhel/7.0/pbis.te#L298-L476
https://github.com/BeyondTrust/pbis-open/blob/master/config/linux/redhat/rhel/7.0/pbis.if

It looks like the expectation for services communicating with powerbroker really is to have access to all var_lib_t and unconfined sockets. We'd rather not allow this by default in openstack-selinux, but we'll look at adding an optional policy that can be enabled when needed.

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.

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.

Created attachment 1541795 [details]
Diff of what solution (1) may look like

Pull request for stopgap solution (2) until (1) is available - https://github.com/redhat-openstack/openstack-selinux/pull/29

Created attachment 1542069 [details]
Example of what solution (3) may look like

Build with "openstack_pbis_support" boolean (#2 above).

This bug is being closed due to the retirement of OSP 8.