Bug 1508336 - Starting openvswitch.service causes AVC denials to be logged
Summary: Starting openvswitch.service causes AVC denials to be logged
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: openvswitch
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Aaron Conole
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1508337 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-01 08:49 UTC by Jan Pazdziora
Modified: 2019-09-13 07:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-27 22:26:08 UTC
Type: Bug


Attachments (Terms of Use)

Description Jan Pazdziora 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 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 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 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 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 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 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 2019-09-13 07:57:19 UTC
To cross-reference, the problem is back in slightly different form in Fedora 30, bug 1751793.


Note You need to log in before you can comment on or make changes to this bug.