Bug 1508336

Summary: Starting openvswitch.service causes AVC denials to be logged
Product: [Fedora] Fedora Reporter: Jan Pazdziora (Red Hat) <jpazdziora>
Component: openvswitchAssignee: Aaron Conole <aconole>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: aconole, apevec, brad.inch, chrisw, fleitner, jpazdziora, mpitt, tgraf, tredaelli
Target Milestone: ---   
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: 2018-11-27 22:26:08 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:

Description Jan Pazdziora (Red Hat) 2017-11-01 08:49:35 UTC
Description of problem:

When openvswitch.service is started, AVC denials about openvswitch_t are logged.

Version-Release number of selected component (if applicable):

openvswitch-2.8.1-1.fc27.x86_64
selinux-policy-3.13.1-283.14.fc27.noarch
kernel-4.13.8-300.fc27.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. systemctl start openvswitch
2. Check the audit.log.

Actual results:

type=AVC msg=audit(1509463697.530:159): avc:  denied  { map } for  pid=12682 comm="modprobe" path="/usr/lib/modules/4.13.8-300.fc27.x86_64/modules.dep.bin" dev="dm-0" ino=246255 scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:modules_object_t:s0 

type=AVC msg=audit(1509463697.538:160): avc:  denied  { module_load } for  pid=12682 comm="modprobe" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=system permissive=0

Expected results:

No AVC denials.

Additional info:

Comment 2 Jan Pazdziora (Red Hat) 2017-11-01 08:55:21 UTC
Note that on Fedora 26, the AVC denials are different: bug 1508337.

Comment 3 Martin Pitt 2017-11-15 10:52:44 UTC
There is a very similar issue, with systemd being denied map access to modules.dep.bin. I filed this as bug 1513399, it's most probably wrong against openvswitch.

Comment 4 Jan Pazdziora (Red Hat) 2017-11-28 08:58:02 UTC
I actually think that the fix belongs to the openvswitch component since that modprobe shouldn't be run with the openvswitch_t context -- that should most probably be done via domain-transitioned helper script that the openvswitch should ship.

Comment 5 Flavio Leitner 2017-11-29 12:22:25 UTC
(In reply to Jan Pazdziora from comment #4)
Could you elaborate more?

Comment 6 Jan Pazdziora (Red Hat) 2017-11-29 12:54:09 UTC
To reduce the attack vectors, my preference would be to separate various security relevant operations (of which loading kernel module most likely is) into separate SELinux domains (contexts), rather than merely adding allows to existing openvswitch_t. It would also make the audit easier.

Comment 7 Flavio Leitner 2017-11-29 13:02:53 UTC
That makes perfect sense.
I was looking for more details about the domain-transitioned helper script.

I think ovs-ctl script used by systemd ovs-vswitchd.service will load the module before starting the ovs-vswitchd daemon.  Maybe that can be done ExecStartPre?

Comment 8 Jan Pazdziora (Red Hat) 2017-11-29 13:12:04 UTC
https://danwalsh.livejournal.com/23944.html talks about domain transitioning in general.

I'm not familiar with the overall openvswitch setup / startup to say which service / script would be the best place for it.

Comment 9 Jan Pazdziora (Red Hat) 2018-03-05 12:45:34 UTC
Is there any progress with the investigation?

Comment 10 Aaron Conole 2018-03-05 20:49:13 UTC
https://github.com/orgcandman/ovs/tree/systemd_enhancements

This branch contains the proposal for the domain-transitioned helper script.  I need to clean up the commits and then submit it upstream.  Once it's accepted we can bring it back.

Comment 11 Alan Pevec 2018-04-09 11:48:26 UTC
Submitted upstream https://mail.openvswitch.org/pipermail/ovs-dev/2018-March/345333.html

Comment 13 Jan Pazdziora (Red Hat) 2018-06-25 09:54:34 UTC
*** Bug 1508337 has been marked as a duplicate of this bug. ***

Comment 14 Ben Cotton 2018-11-27 15:05:57 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Martin Pitt 2018-11-27 22:26:08 UTC
This does not happen any more since Fedora 28.

Comment 16 Jan Pazdziora (Red Hat) 2019-09-13 07:57:19 UTC
To cross-reference, the problem is back in slightly different form in Fedora 30, bug 1751793.