On Thu, Jun 30, 2016 at 4:59 PM, Daniel Jurgens <[email protected]> wrote:
> On 6/30/2016 3:17 PM, Paul Moore wrote:
>> On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens <[email protected]> wrote:
>>> From: Daniel Jurgens <[email protected]>
>>>
>>> Support for Infiniband requires the addition of two new object contexts,
>>> one for infiniband PKeys and another IB End Ports. Added handlers to read
>>> and write the new ocontext types when reading or writing a binary policy
>>> representation.
>>>
>>> Signed-off-by: Daniel Jurgens <[email protected]>
>>> Reviewed-by: Eli Cohen <[email protected]>
>>> ---
>>> security/selinux/include/security.h | 3 +-
>>> security/selinux/ss/policydb.c | 129
>>> +++++++++++++++++++++++++++++++-----
>>> security/selinux/ss/policydb.h | 27 +++++---
>>> 3 files changed, 135 insertions(+), 24 deletions(-)
>> ...
>>
>>> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
>>> index 992a315..78b819c 100644
>>> --- a/security/selinux/ss/policydb.c
>>> +++ b/security/selinux/ss/policydb.c
>>> @@ -2219,6 +2229,58 @@ static int ocontext_read(struct policydb *p, struct
>>> policydb_compat_info *info,
>>> goto out;
>>> break;
>>> }
>>> + case OCON_PKEY: {
>>> + rc = next_entry(nodebuf, fp, sizeof(u32) *
>>> 6);
>>> + if (rc)
>>> + goto out;
>>> +
>>> + c->u.pkey.subnet_prefix =
>>> be64_to_cpu(*((__be64 *)nodebuf));
>>> + /* The subnet prefix is stored as an IPv6
>>> + * address in the policy.
>>> + *
>>> + * Check that the lower 2 DWORDS are 0.
>>> + */
>> Any particular reason why you reusing an IPv6 address format here?
>> Why not use a u64 for the prefix and u16/u32 fields for the partition
>> keys?
>
> The subnet prefix is the high order bytes of an IPv6 address and there is
> infrastructure in place in the userland utilities that deal with IPv6
> addresses (parsing them with a :: to eliminate the need to fill out the 0's
> for example).
Okay, as long as it is a proper IPv6 address, that's fine.
> Regarding u16, the policy is packed with everything in u32, as you can see in
> OCON_NODE6 and OCON_PORT handling.
>>> + if (nodebuf[2] || nodebuf[3]) {
>>> + rc = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> + if (nodebuf[4] > 0xffff ||
>>> + nodebuf[5] > 0xffff) {
>>> + rc = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> + c->u.pkey.low_pkey =
>>> le32_to_cpu(nodebuf[4]);
>>> + c->u.pkey.high_pkey =
>>> le32_to_cpu(nodebuf[5]);
>>> +
>>> + rc =
>>> context_read_and_validate(&c->context[0],
>>> + p,
>>> + fp);
>>> + if (rc)
>>> + goto out;
>>> + break;
>>> + }
>>> + case OCON_IB_END_PORT:
>> This is a little bit of bikeshedding, but is there such thing as an IB
>> "port" that isn't an *end* "port"? Could we simply use OCON_IB_PORT?
>
> Jason Gunthorpe requested that the name be end_port in the RFC series.
His reasoning? Is there a IB port concept that isn't an end port?
--
paul moore
security @ redhat
_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].
