Re: [PATCH 05/12] selinux: Implement Infiniband PKey "Access" access vector

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

 



On 7/1/2016 1:59 PM, Paul Moore wrote:
> On Fri, Jul 1, 2016 at 2:21 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>> On 7/1/2016 11:29 AM, Paul Moore wrote:
>>> I wondered about this earlier in the patchset when we were discussing
>>> the policy format, and I'm still wondering; perhaps you can help me
>>> understand IB a bit better ...
>>>
>>> From what I gather, the partition key is the IB security boundary, not
>>> the subnet, is that true?  If so, why are we including the subnet with
>>> the partition key value/label?  I understand the low/high pkey range
>>> as a way of simplifying the policy, but I don't quite understand the
>>> point of tying the subnet to the partition key label.  Would you ever
>>> want to have multiple labels for a single partition key, or should it
>>> be a single label for the partition key regardless of the subnet?
>>>
>> Each subnet can have a different partition configuration and a node can be on multiple subnets.  By specifying the subnet prefix along with the pkey value the user has flexibility to have different policy for different subnets, instead of a global PKey space that would require coordinating the partition configuration across all subnets.
> Perhaps a better explanation of partitions and subnets are in order,
> especially for those of like me who are new to IB.
>

A subnet is a set of ports managed by a common subnet manager, which sets up the partition configuration.  A partition is a virtual fabric, similar to an VLAN.  If there are multiple IB ports each could be connected to a different subnet.  By including the subnet prefix in the label the subnets can use the same PKey values and policy can restrict access appropriately.  Without that mechanism if one of the subnets had a partition with PKey 1 the other partition couldn't reuse that PKey if a different security policy is desired for that subnet.


_______________________________________________
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