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

[Paul Moore]

On Mon, Jul 11, 2016 at 10:46 AM, Stephen Smalley  wrote:
> I don't think we can/should add any more initial SIDs until we have
> dynamic discovery support for them.  At present, we'll have problems
> with old kernel with new policy and with new kernel with old policy when
> the number of initial SIDs changes.

Seems like a reasonable policy to me.

-- 
paul moore
www.paul-moore.com
___
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.

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

[Stephen Smalley]

On 06/23/2016 03:52 PM, Dan Jurgens wrote:
> From: Daniel Jurgens 
> 
> Add a type and access vector for PKeys. Implement the qp_pkey_access
> and mad_agent_pkey_access hooks to check that the caller has
> permission to access the PKey on the given subnet prefix.  Add an
> interface to get the PKey SID. Walk the PKey ocontexts to find an entry
> for the given subnet prefix and pkey.
> 
> Signed-off-by: Daniel Jurgens 
> Reviewed-by: Eli Cohen 
> ---
>  include/linux/lsm_audit.h|  7 
>  security/selinux/hooks.c | 41 
> 
>  security/selinux/include/classmap.h  |  2 ++
>  security/selinux/include/initial_sid_to_string.h |  1 +
>  security/selinux/include/security.h  |  2 ++
>  security/selinux/ss/services.c   | 41 
> 
>  6 files changed, 94 insertions(+)
> 
> diff --git a/include/linux/lsm_audit.h b/include/linux/lsm_audit.h
> index ffb9c9d..8ff7eae 100644
> --- a/include/linux/lsm_audit.h
> +++ b/include/linux/lsm_audit.h
> @@ -45,6 +45,11 @@ struct lsm_ioctlop_audit {
>   u16 cmd;
>  };
>  
> +struct lsm_pkey_audit {
> + u64 subnet_prefix;
> + u16 pkey;
> +};
> +
>  /* Auxiliary data to use in generating the audit record. */
>  struct common_audit_data {
>   char type;
> @@ -59,6 +64,7 @@ struct common_audit_data {
>  #define LSM_AUDIT_DATA_INODE 9
>  #define LSM_AUDIT_DATA_DENTRY10
>  #define LSM_AUDIT_DATA_IOCTL_OP  11
> +#define LSM_AUDIT_DATA_PKEY  12
>   union   {
>   struct path path;
>   struct dentry *dentry;
> @@ -75,6 +81,7 @@ struct common_audit_data {
>  #endif
>   char *kmod_name;
>   struct lsm_ioctlop_audit *op;
> + struct lsm_pkey_audit *pkey;
>   } u;
>   /* this union contains LSM specific data */
>   union {
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4f13ea4..5a40b10 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -6018,6 +6018,44 @@ static void selinux_unregister_ib_flush_callback(void)
>   mutex_unlock(_flush_mutex);
>  }
>  
> +static int selinux_pkey_access(u64 subnet_prefix, u16 pkey_val, void 
> *security)
> +{
> + struct common_audit_data ad;
> + int err;
> + u32 sid = 0;
> + struct ib_security_struct *sec = security;
> + struct lsm_pkey_audit pkey;
> +
> + err = security_pkey_sid(subnet_prefix, pkey_val, );
> +
> + if (err)
> + goto out;
> +
> + ad.type = LSM_AUDIT_DATA_PKEY;
> + pkey.subnet_prefix = subnet_prefix;
> + pkey.pkey = pkey_val;
> + ad.u.pkey = 
> + err = avc_has_perm(sec->sid, sid,
> +SECCLASS_INFINIBAND_PKEY,
> +INFINIBAND_PKEY__ACCESS, );
> +out:
> + return err;
> +}
> +
> +static int selinux_ib_qp_pkey_access(u64 subnet_prefix, u16 pkey_val,
> +  struct ib_qp_security *qp_sec)
> +{
> + return selinux_pkey_access(subnet_prefix, pkey_val,
> +qp_sec->q_security);
> +}
> +
> +static int selinux_ib_mad_agent_pkey_access(u64 subnet_prefix, u16 pkey_val,
> + struct ib_mad_agent *mad_agent)
> +{
> + return selinux_pkey_access(subnet_prefix, pkey_val,
> + mad_agent->m_security);
> +}
> +
>  static int selinux_ib_qp_alloc_security(struct ib_qp_security *qp_sec)
>  {
>   struct ib_security_struct *sec;
> @@ -6248,6 +6286,9 @@ static struct security_hook_list selinux_hooks[] = {
> selinux_register_ib_flush_callback),
>   LSM_HOOK_INIT(unregister_ib_flush_callback,
> selinux_unregister_ib_flush_callback),
> + LSM_HOOK_INIT(ib_qp_pkey_access, selinux_ib_qp_pkey_access),
> + LSM_HOOK_INIT(ib_mad_agent_pkey_access,
> +   selinux_ib_mad_agent_pkey_access),
>   LSM_HOOK_INIT(ib_qp_alloc_security,
> selinux_ib_qp_alloc_security),
>   LSM_HOOK_INIT(ib_qp_free_security,
> diff --git a/security/selinux/include/classmap.h 
> b/security/selinux/include/classmap.h
> index 1f1f4b2..d42dd4d 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -165,5 +165,7 @@ struct security_class_mapping secclass_map[] = {
> { COMMON_CAP_PERMS, NULL } },
>   { "cap2_userns",
> { COMMON_CAP2_PERMS, NULL } },
> + { "infiniband_pkey",
> +   { "access", NULL } },
>   { NULL }
>};
> diff --git a/security/selinux/include/initial_sid_to_string.h 
> b/security/selinux/include/initial_sid_to_string.h
> index a59b64e..8f2eefc 100644
> --- a/security/selinux/include/initial_sid_to_string.h
> +++ b/security/selinux/include/initial_sid_to_string.h
> @@ -29,5 +29,6 @@ static const char *initial_sid_to_string[] =

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

[Paul Moore]

On Fri, Jul 1, 2016 at 3:57 PM, Daniel Jurgens  wrote:
> On 7/1/2016 2:26 PM, Paul Moore wrote:
>> On Fri, Jul 1, 2016 at 3:16 PM, Daniel Jurgens  wrote:
>>> On 7/1/2016 1:59 PM, Paul Moore wrote:
 On Fri, Jul 1, 2016 at 2:21 PM, Daniel Jurgens  
 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.

Thanks, that clears things up.  Originally I thought it was the other
way around which we causing a lot of confusion on my part.

-- 
paul moore
security @ redhat

___
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.

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

[Daniel Jurgens]

On 7/1/2016 2:26 PM, Paul Moore wrote:
> On Fri, Jul 1, 2016 at 3:16 PM, Daniel Jurgens  wrote:
>> On 7/1/2016 1:59 PM, Paul Moore wrote:
>>> On Fri, Jul 1, 2016 at 2:21 PM, Daniel Jurgens  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.
> 
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@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.

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

[Daniel Jurgens]

On 7/1/2016 1:59 PM, Paul Moore wrote:
> On Fri, Jul 1, 2016 at 2:21 PM, Daniel Jurgens  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@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.

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

[Daniel Jurgens]

On 7/1/2016 11:29 AM, Paul Moore wrote:
> On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens  wrote:
>> From: Daniel Jurgens 
>>
>> Add a type and access vector for PKeys. Implement the qp_pkey_access
>> and mad_agent_pkey_access hooks to check that the caller has
>> permission to access the PKey on the given subnet prefix.  Add an
>> interface to get the PKey SID. Walk the PKey ocontexts to find an entry
>> for the given subnet prefix and pkey.
>>
>> Signed-off-by: Daniel Jurgens 
>> Reviewed-by: Eli Cohen 
>> ---
>>  include/linux/lsm_audit.h|  7 
>>  security/selinux/hooks.c | 41 
>> 
>>  security/selinux/include/classmap.h  |  2 ++
>>  security/selinux/include/initial_sid_to_string.h |  1 +
>>  security/selinux/include/security.h  |  2 ++
>>  security/selinux/ss/services.c   | 41 
>> 
>>  6 files changed, 94 insertions(+)
>>
>> diff --git a/include/linux/lsm_audit.h b/include/linux/lsm_audit.h
>> index ffb9c9d..8ff7eae 100644
>> --- a/include/linux/lsm_audit.h
>> +++ b/include/linux/lsm_audit.h
>> @@ -45,6 +45,11 @@ struct lsm_ioctlop_audit {
>> u16 cmd;
>>  };
>>
>> +struct lsm_pkey_audit {
>> +   u64 subnet_prefix;
>> +   u16 pkey;
>> +};
>> +
>>  /* Auxiliary data to use in generating the audit record. */
>>  struct common_audit_data {
>> char type;
>> @@ -59,6 +64,7 @@ struct common_audit_data {
>>  #define LSM_AUDIT_DATA_INODE   9
>>  #define LSM_AUDIT_DATA_DENTRY  10
>>  #define LSM_AUDIT_DATA_IOCTL_OP11
>> +#define LSM_AUDIT_DATA_PKEY12
>> union   {
>> struct path path;
>> struct dentry *dentry;
>> @@ -75,6 +81,7 @@ struct common_audit_data {
>>  #endif
>> char *kmod_name;
>> struct lsm_ioctlop_audit *op;
>> +   struct lsm_pkey_audit *pkey;
>> } u;
>> /* this union contains LSM specific data */
>> union {
> Please correct me if I'm wrong, but I don't recall seeing any code in
> the patchset which actually logs the extra IB information in the audit
> record, did I miss it?
I didn't make any changes to the audit logging.  The messages look like this.
[245259.895597] audit: type=1400 audit(1467392186.710:631): avc:  denied  { 
access } for  pid=27519 comm="ib_write_bw" scontext=root:sysadm_r:sysadm_t:s0 
tcontext=system_u:object_r:staff_allowed_pkey_t:s0 tclass=infiniband_pkey 
permissive=1

> 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.


___
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.