On 5/22/2017 5:59 PM, Chris PeBenito wrote:
> On 05/18/2017 07:39 AM, Daniel Jurgens wrote:
>> On 5/17/2017 5:10 PM, Chris PeBenito wrote:
>>> On 05/17/2017 11:45 AM, Dan Jurgens via refpolicy wrote:
>>>> From: Daniel Jurgens <[email protected]>
>>>>
>>>> +########################################
>>>> +## <summary>
>>>> +## Access unlabeled infiniband pkeys.
>>>> +## </summary>
>>>> +## <param name="domain">
>>>> +## <summary>
>>>> +## Domain allowed access.
>>>> +## </summary>
>>>> +## </param>
>>>> +#
>>>> +interface(`corenet_ibpkey_access_unlabeled_pkeys',`
>>> I'm wondering if we could simplify these interface names a little, such
>>> as corenet_ib_access_unlabeled_pkeys(). It would also change the above
>>> and below interface names to corenet_ib_pkey() and corenet_ib_endport()
>> I can shorten the names.
>>
>>>> + gen_require(`
>>>> + type unlabeled_t;
>>>> + ')
>>>> +
>>>> + allow $1 unlabeled_t:infiniband_pkey { access };
>>> Here and below the patch, I'd prefer to skip the unnecessary braces
>>> around the single permission, to keep the visual clutter down.
>>>
>>> Additionally, the challenge is that unlabeled_t doesn't belong to this
>>> module, so it shouldn't be referenced directly.
>> I'd like to allow access to all unlabeled pkeys out of the box, most infiniband users will want that type of behavior. Since there's no initial SID for pkeys they are unlabeled_t by default.
>>
>> Can you suggest a way to do this without a direct reference to unlabeled_t?
> See the unlabeled packet interface in corenetwork for an example.
>
>>>> +')
>>>> +
>>>> +########################################
>>>> +## <summary>
>>>> +## Access all labeled infiniband pkeys.
>>>> +## </summary>
>>>> +## <param name="domain">
>>>> +## <summary>
>>>> +## Domain allowed access.
>>>> +## </summary>
>>>> +## </param>
>>>> +#
>>>> +interface(`corenet_ibpkey_access_all_labeled_pkeys',`
>>> I think the "labeled" should be dropped here and latter interfaces, as
>>> it is inconsistent with how we handle interface naming for accessing
>>> attributes.
>>>
>> Here I'd like to have a difference between all pkey (labeled or unlabeled, which kernel_t needs permission for) and only those that are unlabeled (for sysadm and staff roles). The resolution of this comment is related to the question I asked above.
> The way to do that is to have an interface for unlabeled pkeys and one
> for all pkeys, which would be pkeys that have a specific label. Then if
> you need access to both, you call both interfaces.
>
Thank you Chris, I've addressed your comments and sent v1.