RE: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: ira.weiny [mailto:ira.weiny@xxxxxxxxx]

> >
> > It really isn't. net ports and service_ids are global things that do
> > not need machine-specific customizations while subnet prefix or device
> > name/port are both machine-local information.
> 
> I agree that service_ids are more analogous to net ports.
> 
> However, subnet prefixes are _not_ machine-local.  They are controlled by the
> Admin of the fabric by a central entity (the SM).  This is more helpful than in
> ethernet where if you configure the wrong port with the wrong subnet things
> just don't work.  In IB I can physically plug my network into any IB port I want
> and the system is _told_ which "subnet" that port belongs to.  (OPA is the same
> way.)
> 
> So for IB/OPA a subnet prefix is a really good way to ID which network (subnet)
> you want to use.  Unfortunately, I'm not sure how to translate that to
> iwarp/roce seamlessly except to have some concept of "domain" as I mentioned
> in my other email.
> 

Exactly. The identity of both the "domain" (the subnet ID) and the "label" stem from a central entity - the SM.
It would be very natural to have IB/OPA subnet policies that are configured in all hosts and the SM. These policies are automatically enforced for any port connected to the subnet.

Not everything needs to be related to IP interfaces.
I can envision multiple jobs in the cluster, running on distinct partitions using distinct security tags, without configuring IP interfaces on these partitions.
Partition security is a useful and an effective measure that is applicable to IB/OPA networks. That's it.

Ethernet VLANs are a totally different thing --- SELinux *already* handles them for Ethernet interfaces.
There is nothing special from an admin's point of view regarding how SELinux applies to RDMA over Ethernet (RoCE/iWarp). RDMA is just another transport, and any Ethernet L2 policies should apply to it seamlessly.

--Liran


_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux