Bug 1309361 - [Hyper-V][RHEL7.3]Grant hyperv-daemons access to /dev/vmbus/hv_* devices
[Hyper-V][RHEL7.3]Grant hyperv-daemons access to /dev/vmbus/hv_* devices
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Lukas Vrabec
Jaroslav Aster
Depends On:
Blocks: 1304005
  Show dependency treegraph
Reported: 2016-02-17 10:43 EST by Vitaly Kuznetsov
Modified: 2016-11-03 22:42 EDT (History)
15 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-68.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1331448 (view as bug list)
Last Closed: 2016-11-03 22:42:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2283 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2016-11-03 09:36:25 EDT

  None (edit)
Description Vitaly Kuznetsov 2016-02-17 10:43:01 EST
Description of problem:
This is RHEL7 clone of the following Fedora BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1241636

I plan to upgrade hyperv-daemons package switching hypervvssd and hypervkvpd daemons to using char devices instead of netlink to communicate with kernel. To support the change I need to grant the following:

/usr/sbin/hypervvssd needs to access /dev/vmbus/hv_vss (open, read, write)

/usr/sbin/hypervkvpd needs to access /dev/vmbus/hv_kvp (open, read, write)

audit2allow generates the following:
#============= hypervkvp_t ==============
allow hypervkvp_t device_t:chr_file { read write open };

#============= hypervvssd_t ==============
allow hypervvssd_t device_t:chr_file { read write open };

This is sufficient but seems to be to permissive, not sure if we can assign different labels to /dev/vmbus/hv_* devices but if it's the case we can limit each daemon (hypervvssd, hypervkvpd, hypervfcopyd) to accessing its own char device.
Comment 2 Milos Malik 2016-02-19 03:08:11 EST
How are these devices created? Do I need to load some kernel module?
Comment 3 Vitaly Kuznetsov 2016-02-19 05:07:59 EST
These devices are created by hv_utils kernel module but your VM needs to run on a Hyper-V host with Guest integration services enabled. Virt QE (in CC: for this BZ, yacao@, leiwang@,...) can provide a VM for testing, I guess. You'll also need to use an updated kernel to see hv_kvp and hv_vss devices, I plan to put the required patches with https://bugzilla.redhat.com/show_bug.cgi?id=1074407 backport. I'll provide a brew build and hyperv-daemons build for early testing shortly.
Comment 5 Mike McCune 2016-03-28 19:00:31 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 10 xuli 2016-07-18 23:00:23 EDT
Verify Pass on latest build.
Host: Windows server 2016 TP5
Guest:RHEL7.3 Gen1 (3.10.0-469.el7.x86_64) 

Verify steps are same with comment 7 described, also do function test of hyperv-daemons, including hypervkvpd, hypervfcopyd,hypervvssd related test cases.
Cover the scenarios mentioned:
1) Be able to get IP information from your host for both static and DHCP cases.
2) Be able to set IP ('ip injection').
3) Be able to set 'Failover IP'.

Note: for different ausearch log after ip-injection, which is tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1349356, so close this bug.
Comment 14 errata-xmlrpc 2016-11-03 22:42:56 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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