Bug 1517744

https://bugzilla.redhat.com/show_bug.cgi?id=1464478#c90

Fix in Fedora: 

commit 090161c49fc49d31633634095b6227e18e3215dd (HEAD -> rawhide, origin/rawhide, origin/HEAD)
Author: Lukas Vrabec <lvrabec>
Date:   Tue Nov 28 17:30:03 2017 +0100

    Allow domains networkmanager_t and opensm_t to control IPoIB VLANs

(In reply to Lukas Vrabec from comment #3)
> Fix in Fedora: 
> 
> commit 090161c49fc49d31633634095b6227e18e3215dd (HEAD -> rawhide,
> origin/rawhide, origin/HEAD)
> Author: Lukas Vrabec <lvrabec>
> Date:   Tue Nov 28 17:30:03 2017 +0100
> 
>     Allow domains networkmanager_t and opensm_t to control IPoIB VLANs

Can we (minimally) get a (test) build for 7.5 so we can run tests on it tonight,
along with the kernel I pointed to here:
 https://bugzilla.redhat.com/show_bug.cgi?id=1464478#c93

(In reply to Don Dutile from comment #5)
> Can we (minimally) get a (test) build for 7.5 so we can run tests on it
> tonight,
> along with the kernel I pointed to here:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1464478#c93

I forgot that Lukas is away at training all of this week (sorry Lukas!).  I'm currently working on a crude patch/scratch-build to use for testing, see BZ 1464478.

(In reply to Don Dutile from comment #5)
> (In reply to Lukas Vrabec from comment #3)
> > Fix in Fedora: 
> > 
> > commit 090161c49fc49d31633634095b6227e18e3215dd (HEAD -> rawhide,
> > origin/rawhide, origin/HEAD)
> > Author: Lukas Vrabec <lvrabec>
> > Date:   Tue Nov 28 17:30:03 2017 +0100
> > 
> >     Allow domains networkmanager_t and opensm_t to control IPoIB VLANs
> 
> Can we (minimally) get a (test) build for 7.5 so we can run tests on it
> tonight,
> along with the kernel I pointed to here:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1464478#c93

I tested this kernel (with upstream v2 patch) with my scratch selinux-policy package (only IPoIB patch applied). It does not make any difference.

Now a v3 upstream kernel patch is available. I'm waiting for a scratch kernel with v3 patch.

(In reply to Honggang LI from comment #9)
> I tested this kernel (with upstream v2 patch) with my scratch selinux-policy
> package (only IPoIB patch applied). It does not make any difference.

To clarify, you are still seeing the same problems with SELinux access denials for NetworkManager and opensm?  If so, can you please share the audit records showing the denials?

(In reply to Honggang LI from comment #9)
> (In reply to Don Dutile from comment #5)
> > (In reply to Lukas Vrabec from comment #3)
> > > Fix in Fedora: 
> > > 
> > > commit 090161c49fc49d31633634095b6227e18e3215dd (HEAD -> rawhide,
> > > origin/rawhide, origin/HEAD)
> > > Author: Lukas Vrabec <lvrabec>
> > > Date:   Tue Nov 28 17:30:03 2017 +0100
> > > 
> > >     Allow domains networkmanager_t and opensm_t to control IPoIB VLANs
> > 
> > Can we (minimally) get a (test) build for 7.5 so we can run tests on it
> > tonight,
> > along with the kernel I pointed to here:
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1464478#c93
> 
> I tested this kernel (with upstream v2 patch) with my scratch selinux-policy
> package (only IPoIB patch applied). It does not make any difference.
> 
> Now a v3 upstream kernel patch is available. I'm waiting for a scratch
> kernel with v3 patch.

The v3 kernel is the same as the v2 kernel, except it gets around the kernel build warning in a different way ... setting new_pps to NULL and using it as a check in the second if in security.c.  there will be no functional difference with v3 vs v2. 

If this kernel & selinux policy update doesn't work, I have to ask: what is Mellanox using & testing to see that these patches fix the problem/issue?

(In reply to Paul Moore from comment #10)
> (In reply to Honggang LI from comment #9)
> > I tested this kernel (with upstream v2 patch) with my scratch selinux-policy
> > package (only IPoIB patch applied). It does not make any difference.
> 
> To clarify, you are still seeing the same problems with SELinux access
> denials for NetworkManager and opensm?  

I saw the same problems with SELinux access with Don's scratch kernel with the old in-box selinux-policy package. If patched selinux-policy package installed, IPoIB vlan works as expected.

(In reply to Don Dutile from comment #11)

> If this kernel & selinux policy update doesn't work, I have to ask: what is
> Mellanox using & testing to see that these patches fix the problem/issue?

The selinux-policy update fixes the IPoIB vlan issue. But the kernel update is helpless for the IPoIB vlan issue. I did not test the opensm issue yet.

(In reply to Honggang LI from comment #13)
> (In reply to Don Dutile from comment #11)
> 
> > If this kernel & selinux policy update doesn't work, I have to ask: what is
> > Mellanox using & testing to see that these patches fix the problem/issue?
> 
> The selinux-policy update fixes the IPoIB vlan issue. But the kernel update
> is helpless for the IPoIB vlan issue. I did not test the opensm issue yet.

ok, I'm confused. Do you mean that your scratch selinux-policy build failed, but the one Lukas built did work?

the kernel fix will only work for iWARP-based RDMA -- it ignores the check for non-Pkey'd interface (iWARP).

(In reply to Don Dutile from comment #14)
> (In reply to Honggang LI from comment #13)
> > (In reply to Don Dutile from comment #11)
> > 
> > > If this kernel & selinux policy update doesn't work, I have to ask: what is
> > > Mellanox using & testing to see that these patches fix the problem/issue?
> > 
> > The selinux-policy update fixes the IPoIB vlan issue. But the kernel update
> > is helpless for the IPoIB vlan issue. I did not test the opensm issue yet.
> 
> ok, I'm confused. Do you mean that your scratch selinux-policy build failed,
> but the one Lukas built did work?

Mo, I never tested Lukas build, it was not ready until this morning. I only tested my scratch selinux-policy build.

It seems the selinux-policy still emits warning message about opensm.

[root@rdma03 ~]# uname -r 
4.14.0.0c86a6bd85ff

[root@rdma03 ~]# rpm -qa | grep  opensm
opensm-libs-3.3.20-2.el7.x86_64
opensm-3.3.20-2.el7.x86_64

[root@rdma03 ~]# rpm -qa | grep selinux-policy
selinux-policy-targeted-3.13.1-180.el7.pkeys.100.noarch
selinux-policy-devel-3.13.1-180.el7.noarch
selinux-policy-3.13.1-180.el7.pkeys.100.noarch

[root@rdma03 ~]# grep -v '^#' /etc/selinux/config 
SELINUX=permissive
SELINUXTYPE=targeted

[root@rdma03 ~]# getenforce 
Permissive

[root@rdma03 ~]# ausearch -x opensm
----
time->Tue Nov 28 21:55:52 2017
type=PROCTITLE msg=audit(1511924152.624:75): proctitle=2F7573722F7362696E2F6F70656E736D002D6700307830303032633930333030623363666632002D2D7375626E65745F70726566697800307866653830303030303030303030303031
type=SYSCALL msg=audit(1511924152.624:75): arch=c000003e syscall=16 success=yes exit=0 a0=5 a1=c01c1b01 a2=7ffe7c4f8e30 a3=7ffe7c4f8be0 items=0 ppid=1975 pid=1976 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="opensm" exe="/usr/sbin/opensm" subj=system_u:system_r:opensm_t:s0 key=(null)
type=AVC msg=audit(1511924152.624:75): avc:  denied  { manage_subnet } for  pid=1976 comm="opensm" device=mlx4_0 port_num=2 scontext=system_u:system_r:opensm_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=infiniband_endport permissive=1

[root@rdma03 ~]# ibstat
CA 'mlx4_0'
	CA type: MT4099
	Number of ports: 2
	Firmware version: 2.35.5100
	Hardware version: 1
	Node GUID: 0x0002c90300b3cff0
	System image GUID: 0x0002c90300b3cff3
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 56
		Base lid: 2
		LMC: 0
		SM lid: 2
		Capability mask: 0x0259486a
		Port GUID: 0x0002c90300b3cff1
		Link layer: InfiniBand
	Port 2:
		State: Active
		Physical state: LinkUp
		Rate: 56
		Base lid: 3
		LMC: 0
		SM lid: 3
		Capability mask: 0x0259486a
		Port GUID: 0x0002c90300b3cff2
		Link layer: InfiniBand
[root@rdma03 ~]#

(In reply to Honggang LI from comment #15)
> (In reply to Don Dutile from comment #14)
> > (In reply to Honggang LI from comment #13)
> > > (In reply to Don Dutile from comment #11)
> > > 
> > > > If this kernel & selinux policy update doesn't work, I have to ask: what is
> > > > Mellanox using & testing to see that these patches fix the problem/issue?
> > > 
> > > The selinux-policy update fixes the IPoIB vlan issue. But the kernel update
> > > is helpless for the IPoIB vlan issue. I did not test the opensm issue yet.
> > 
> > ok, I'm confused. Do you mean that your scratch selinux-policy build failed,
> > but the one Lukas built did work?
> 
> Mo, I never tested Lukas build, it was not ready until this morning. I only
> tested my scratch selinux-policy build.

Please test the selinux-policy scratch-build from Lukas.  Regardless of the kernel used for testing there are also SELinux policy problems and the scratch-build from Lukas *should* resolve those.

(In reply to Paul Moore from comment #17)

> Please test the selinux-policy scratch-build from Lukas.  Regardless of the
> kernel used for testing there are also SELinux policy problems and the
> scratch-build from Lukas *should* resolve those.

See https://bugzilla.redhat.com/show_bug.cgi?id=1517744#c16
    https://bugzilla.redhat.com/show_bug.cgi?id=1517895#c5

Lukas, see Honggang LI's comments above, it appears the infiniband_endport:manage_subnet permission is missing for opensm_t/unlabeled_t.  I believe we need the following for opensm_t:

  +# SELinux/IB hack - https://bugzilla.redhat.com/show_bug.cgi?id=1517744
  +corenet_ib_access_unlabeled_pkeys(opensm_t)
  +corenet_ib_manage_subnet_unlabeled_endports(opensm_t)

I'm guessing your patch has the first line, but not the second.

Yep, You're right. Fixed.

Thanks.

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.

https://access.redhat.com/errata/RHBA-2018:0763