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 2:26 PM, Paul Moore wrote:
> On Fri, Jul 1, 2016 at 3:16 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>> 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.
> So there can be multiple partitions inside a subnet and not multiple
> subnets inside a partition?

Yes, a each subnet can have many partitions.  The partitions are contained within that subnet, a different subnet can have a partition that uses same PKey value, but that's a different partition.  So if we have 2 subnets, fe80:: and fe81:: they can each have a partition that uses PKey X but it doesn't mean nodes with access to that partition on 0xfe80 can reach nodes on 0xfe81 on that partition.

>
>> A partition is a virtual fabric, similar to an VLAN.
> Yeah, I've read that in multiple places and I think that is what I
> find confusing as it doesn't seem to mesh with my understanding of
> what you are intending.
>
>> If there are multiple IB ports each could be connected to a different subnet.
> Ports are just end points, I get that.  That's important, but it isn't
> helping me understand the relationship between subnets and partitions,
> that is where I'm struggling at the moment.

Subnets have one or more partitions.  Partitions belong to one subnet.

>> By including the subnet prefix in the label the subnets can use the same PKey values and policy can restrict access appropriately.
> This doesn't make any sense to me right now.
>
>> 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.
> <blank stare>
Going back to the example above assume fe80:: has a partition using PKey 0x8001 and we grant a user access.  Without the subnet prefix in the label we are granting that user the ability to use pkey 0x8001 on any partition available.  So subnet fe81:: can't use PKey 0x8001 if it doesn't want to grant that same user access.  By labeling with the subnet prefix we can grant access to PKey 0x8001 on subnet fe80:: only, leaving the subnet manager on fe81:: the ability to use that same PKey but not grant access to said user.

_______________________________________________
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