Bug 2054323

Summary: OVS IPsec daemon - permission denied by sellinux
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Harel Braha <hbraha>
Component: openvswitch-selinux-extra-policyAssignee: Aaron Conole <aconole>
Status: CLOSED DUPLICATE QA Contact: Jean-Tsung Hsiao <jhsiao>
Severity: high Docs Contact:
Priority: unspecified    
Version: FDP 22.LCC: amusil, bstinson, ctrautma, jwboyer, lvrabec, malonso, mmalik, mpattric, mperina, msobczyk, qding, ssekidde
Target Milestone: ---Flags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-11 16:51:59 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:
Attachments:
Description Flags
audit.log none

Description Harel Braha 2022-02-14 17:10:46 UTC
Created attachment 1861023 [details]
audit.log

Description of problem:

Selinux blocks the ipsec deamon from accessing /etc/ipsec.conf. 

How reproducible:
every time

Steps to Reproduce:
1. run ovirt-host-deploy playbook 
failure when invokes
ovirt-provider-ovn-driver role - configure.yml - task : "Configure OVN for oVirt".

Actual results:

journalctl -xeu openvswitch-ipsec.service
ovs|  2  | ovs-monitor-ipsec | ERR | traceback
Traceback (most recent call last):
File "/usr/share/openvswitch/scripts/ovs-monitor-ipsec", line 12>
 main()
 File "/usr/share/openvswitch/scripts/ovs-monitor-ipsec", line 12>
 monitor = IPsecMonitor(root_prefix, args.ike_daemon,
 File "/usr/share/openvswitch/scripts/ovs-monitor-ipsec", line 98>
 self.ike_helper.restart_ike_daemon()
 File "/usr/share/openvswitch/scripts/ovs-monitor-ipsec", line 46>
f = open(self.IPSEC_CONF, "w")
 PermissionError: [Errno 13] Permission denied: '/etc/ipsec.conf'

Expected results:
no errors

Additional info:
attached audit.log

Comment 1 Zdenek Pytela 2022-02-21 12:55:06 UTC
Switching the component to openswitch to be assessed and possibly addressed there - I am not completely sure about the openvswitch-selinux-extra-policy status.

Do you think these permissions requests are reasonable?
For those which are, should they be a part of openvswitch-selinux-extra-policy or selinux-policy?

Please ignore the lldpad-related denials.

Comment 2 Mike Pattrick 2022-03-10 16:57:25 UTC
I see the following block, which appears related:

type=AVC msg=audit(1644857302.735:2071): avc:  denied  { write } for  pid=7057 comm="ovs-monitor-ips" name="ipsec.conf" dev="vda10" ino=1786537 scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:ipsec_conf_file_t:s0 tclass=file permissive=0

The OVS selinux policy is supposed to add:

allow openvswitch_t ipsec_conf_file_t:file { getattr ioctl open read write };

Which would allow this action. Can you confirm which version of openvswitch-selinux-extra-policy is installed?

Comment 3 Ales Musil 2022-03-11 06:22:25 UTC
I can see openvswitch-selinux-extra-policy-1.0-30.el9s.noarch on the host.

Comment 4 Mike Pattrick 2022-03-11 16:47:06 UTC
Thank you for that.

I installed the 1.0.30 rpm on RHEL9 and confirmed that it wasn't working, I got the following error when trying to load it:

# semodule -i  /usr/share/selinux/packages/openvswitch-custom.pp
Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/400/openvswitch-custom/cil:74
Failed to resolve AST
semodule:  Failed!

I then compiled 1.0.30 from source code myself and it seemed to work fine. Finally, I tried the most recent release, which is 1.0.31, and it also worked.

For now, I recommend upgrading to 1.0.31, which can be downloaded from here: http://download.eng.bos.redhat.com/brewroot/vol/rhel-9/packages/openvswitch-selinux-extra-policy/1.0/31.el9fdp/noarch/openvswitch-selinux-extra-policy-1.0-31.el9fdp.noarch.rpm

I'll look into why the 1.0.30 package had this issue.

Comment 5 Mike Pattrick 2022-03-11 16:51:59 UTC

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