> From: ira.weiny [mailto:ira.we...@intel.com]

> >
> > 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@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Reply via email to