Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Paul Moore]

On Thu, May 4, 2017 at 11:51 AM, Paul Moore  wrote:
> On Wed, May 3, 2017 at 3:45 PM, Daniel Jurgens  wrote:
>> On 5/3/2017 9:41 AM, Paul Moore wrote:
>>> On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens  wrote:
 From: Daniel Jurgens 

 Infiniband applications access HW from user-space -- traffic is generated
 directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
 which are associated directly with HW transport endpoints, are a natural
 choice for enforcing granular mandatory access control for Infiniband. QPs 
 may
 only send or receives packets tagged with the corresponding partition key
 (PKey). The PKey is not a cryptographic key; it's a 16 bit number 
 identifying
 the partition ...

>>> Hi Dan,
>>>
>>> I haven't heard anything from you in a while, where do things stand
>>> with this effort?  Unless I missed them, I believe we are still
>>> waiting on the userspace, SELinux reference policy, and
>>> selinux-testsuite patches.
>>>
>> Hi Paul,
>>
>> I got distracted for a while.  I've just rebased the kernel and 
>> userspace.  I'll do some testing and submit the userspace code in the next 
>> couple days.  I still have to write the selinux-testsuite tests, I'll work 
>> on those concurrently with the userspace review cycle.
>
> Great, thanks for the update.  We'll look forward to the patches.

I took a closer look at the patchset and I think it looks fine,
coupled with the recent progress on the SELinux userspace and test
suite I think it would be good to get this into the selinux/next tree
so we can start playing with it.  Dan, I know there were some IB merge
conflicts with this patch could you do a respin against the current
selinux/next tree?

* git://git.infradead.org/users/pcmoore/selinux
* http://git.infradead.org/users/pcmoore/selinux

Thanks.

-- 
paul moore
www.paul-moore.com

Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Daniel Jurgens]

On 5/3/2017 9:41 AM, Paul Moore wrote:
> On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens  wrote:
>> From: Daniel Jurgens 
>>
>> Infiniband applications access HW from user-space -- traffic is generated
>> directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
>> which are associated directly with HW transport endpoints, are a natural
>> choice for enforcing granular mandatory access control for Infiniband. QPs 
>> may
>> only send or receives packets tagged with the corresponding partition key
>> (PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
>> the partition.
>>
>> Every Infiniband fabric is controlled by a central Subnet Manager (SM). The 
>> SM
>> provisions the partitions by assigning each port with the partitions it can
>> access. In addition, the SM tags each port with a subnet prefix, which
>> identifies the subnet. Determining which users are allowed to access which
>> partition keys on a given subnet forms an effective policy for isolating 
>> users
>> on the fabric. Any application that attempts to send traffic on a given 
>> subnet
>> is automatically subject to the policy, regardless of which device and port 
>> it
>> uses. SM software configures the subnet through a privileged Subnet 
>> Management
>> Interface (SMI), which is presented by each Infiniband port. Thus, the SMI 
>> must
>> also be controlled to prevent unauthorized changes to fabric configuration 
>> and
>> partitioning.
>>
>> To support access control for IB partitions and subnet management, security
>> contexts must be provided for two new types of objects - PKeys and IB ports.
>>
>> A PKey label consists of a subnet prefix and a range of PKey values and is
>> similar to the labeling mechanism for netports. Each Infiniband port can 
>> reside
>> on a different subnet. So labeling the PKey values for specific subnet 
>> prefixes
>> provides the user maximum flexibility, as PKey values may be determined
>> independently for different subnets. There is a single access vector for 
>> PKeys
>> called "access".
>>
>> An Infiniband port is labeled by device name and port number. There is a 
>> single
>> access vector for IB ports called "manage_subnet".
>>
>> Because RDMA allows kernel bypass, enforcement must be done during connection
>> setup. Communication over RDMA requires a send and receive queue, 
>> collectively
>> known as a Queue Pair (QP). A QP must be initialized by privileged system 
>> calls
>> before it can be used to send or receive data. During initialization the user
>> must provide the PKey and port the QP will use; at this time access control 
>> can
>> be enforced.
>>
>> Because there is a possibility that the enforcement settings or security
>> policy can change, a means of notifying the ib_core module of such changes
>> is required. To facilitate this a generic notification callback mechanism
>> is added to the LSM. One callback is registered for checking the QP PKey
>> associations when the policy changes. Mad agents also register a callback,
>> they cache the permission to send and receive SMPs to avoid another per
>> packet call to the LSM.
>>
>> Because frequent accesses to the same PKey's SID is expected a cache is
>> implemented which is very similar to the netport cache.
>>
>> In order to properly enforce security when changes to the PKey table or
>> security policy or enforcement occur ib_core must track which QPs are
>> using which port, pkey index, and alternate path for every IB device.
>> This makes operations that used to be atomic transactional.
>>
>> When modifying a QP, ib_core must associate it with the PKey index, port,
>> and alternate path specified. If the QP was already associated with
>> different settings, the QP is added to the new list prior to the
>> modification. If the modify succeeds then the old listing is removed. If
>> the modify fails the new listing is removed and the old listing remains
>> unchanged.
>>
>> When destroying a QP the ib_qp structure is freed by the decive specific
>> driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
>> security related information in a separate structure. When a 'destroy'
>> request is in process the ib_qp structure is in an undefined state so if
>> there are changes to the security policy or PKey table, the security checks
>> cannot reset the QP if it doesn't have permission for the new setting. If
>> the 'destroy' fails, security for that QP must be enforced again and its
>> status in the list is restored. If the 'destroy' succeeds the security info
>> can be cleaned up and freed.
>>
>> There are a number of locks required to protect the QP security structure
>> and the QP to device/port/pkey index lists. If multiple locks are required,
>> the safe locking order is: QP security structure mutex first, followed by
>> any list locks needed, which are sorted first by port followed by pkey
>> index.
> Hi Dan,
>
> I haven't heard 

Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Paul Moore]

On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens  wrote:
> From: Daniel Jurgens 
>
> Infiniband applications access HW from user-space -- traffic is generated
> directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
> which are associated directly with HW transport endpoints, are a natural
> choice for enforcing granular mandatory access control for Infiniband. QPs may
> only send or receives packets tagged with the corresponding partition key
> (PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
> the partition.
>
> Every Infiniband fabric is controlled by a central Subnet Manager (SM). The SM
> provisions the partitions by assigning each port with the partitions it can
> access. In addition, the SM tags each port with a subnet prefix, which
> identifies the subnet. Determining which users are allowed to access which
> partition keys on a given subnet forms an effective policy for isolating users
> on the fabric. Any application that attempts to send traffic on a given subnet
> is automatically subject to the policy, regardless of which device and port it
> uses. SM software configures the subnet through a privileged Subnet Management
> Interface (SMI), which is presented by each Infiniband port. Thus, the SMI 
> must
> also be controlled to prevent unauthorized changes to fabric configuration and
> partitioning.
>
> To support access control for IB partitions and subnet management, security
> contexts must be provided for two new types of objects - PKeys and IB ports.
>
> A PKey label consists of a subnet prefix and a range of PKey values and is
> similar to the labeling mechanism for netports. Each Infiniband port can 
> reside
> on a different subnet. So labeling the PKey values for specific subnet 
> prefixes
> provides the user maximum flexibility, as PKey values may be determined
> independently for different subnets. There is a single access vector for PKeys
> called "access".
>
> An Infiniband port is labeled by device name and port number. There is a 
> single
> access vector for IB ports called "manage_subnet".
>
> Because RDMA allows kernel bypass, enforcement must be done during connection
> setup. Communication over RDMA requires a send and receive queue, collectively
> known as a Queue Pair (QP). A QP must be initialized by privileged system 
> calls
> before it can be used to send or receive data. During initialization the user
> must provide the PKey and port the QP will use; at this time access control 
> can
> be enforced.
>
> Because there is a possibility that the enforcement settings or security
> policy can change, a means of notifying the ib_core module of such changes
> is required. To facilitate this a generic notification callback mechanism
> is added to the LSM. One callback is registered for checking the QP PKey
> associations when the policy changes. Mad agents also register a callback,
> they cache the permission to send and receive SMPs to avoid another per
> packet call to the LSM.
>
> Because frequent accesses to the same PKey's SID is expected a cache is
> implemented which is very similar to the netport cache.
>
> In order to properly enforce security when changes to the PKey table or
> security policy or enforcement occur ib_core must track which QPs are
> using which port, pkey index, and alternate path for every IB device.
> This makes operations that used to be atomic transactional.
>
> When modifying a QP, ib_core must associate it with the PKey index, port,
> and alternate path specified. If the QP was already associated with
> different settings, the QP is added to the new list prior to the
> modification. If the modify succeeds then the old listing is removed. If
> the modify fails the new listing is removed and the old listing remains
> unchanged.
>
> When destroying a QP the ib_qp structure is freed by the decive specific
> driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
> security related information in a separate structure. When a 'destroy'
> request is in process the ib_qp structure is in an undefined state so if
> there are changes to the security policy or PKey table, the security checks
> cannot reset the QP if it doesn't have permission for the new setting. If
> the 'destroy' fails, security for that QP must be enforced again and its
> status in the list is restored. If the 'destroy' succeeds the security info
> can be cleaned up and freed.
>
> There are a number of locks required to protect the QP security structure
> and the QP to device/port/pkey index lists. If multiple locks are required,
> the safe locking order is: QP security structure mutex first, followed by
> any list locks needed, which are sorted first by port followed by pkey
> index.

Hi Dan,

I haven't heard anything from you in a while, where do things stand
with this effort?  Unless I missed them, I believe we are still
waiting on the userspace, SELinux reference policy, 

Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Paul Moore]

On Wed, Jan 25, 2017 at 12:25 PM, Doug Ledford  wrote:
> On Wed, 2017-01-25 at 02:58 -0500, Paul Moore wrote:
>> On Tue, Jan 24, 2017 at 4:40 PM, Doug Ledford 
>> wrote:
>> >
>> > On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
>> > >
>> > > On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens > > > x.co
>> > > m> wrote:
>> > > >
>> > > >
>> > > > On 12/13/2016 9:01 AM, Stephen Smalley wrote:
>> > > > >
>> > > > >
>> > > > > For the LSM/SELinux bits,
>> > > > > Acked-by: Stephen Smalley 
>> > > > >
>> > > > > Note that there will be a merge conflict on classmap.h due to
>> > > > > commits in
>> > > > > the selinux next branch, but that should be easy to resolve.
>> > > > >
>> > > > > We'll need the patches for the selinux userspace and
>> > > > > refpolicy.
>> > > >
>> > > > Thanks Stephen, I need to rebase the user space and do some
>> > > > patch
>> > > > breakup.  I'll start on that soon.
>> > >
>> > > Sorry, I haven't had a chance to look at v6, but considering all
>> > > our
>> > > discussions on the previous versions I don't expect any issues
>> > > from
>> > > me.  I was hoping for some more generic hooks/controls, but that
>> > > doesn't look to be possible given the nature of RDMA.  I also
>> > > want to
>> > > mention again the need for tests; we've talked about this in the
>> > > past
>> > > and while it isn't possible to run the tests without IB hardware,
>> > > I
>> > > would like to see us merge tests into the selinux-testsuite so
>> > > that
>> > > those who do have the required h/w available could run the tests.
>> > >
>> > > Assuming we can sort out the SELinux userspace and and tests by
>> > > the
>> > > end of January, I see no reason why this couldn't go in for
>> > > v4.11.
>> >
>> > Daniel, can you work with people on the userspace and tests?  I'll
>> > pull
>> > this into a branch (I assume by Paul's and Stephen's comments that
>> > they
>> > expect it to go through my tree) ready to go, but hold actually
>> > submitting it in the merge window until I've heard more from you
>> > all
>> > that userspace is ready.
>>
>> I don't have a problem pulling this in via the SELinux tree, assuming
>> you are okay with that Doug.  I'm just waiting to see tests for the
>> selinux-testsuite first.
>
> When I tried to apply the patchset, the conflicts started on the very
> first file of the very first patch.  It can go through your tree, but I
> suspect there will be lots of conflicts that way as this upcoming
> release has been touching the cache area of the IB stack and so does
> this code.  There might be significant SELinux conflicts too, I don't
> know, but we know there are IB ones so far.

My apologies, I should have been more clear.  What I meant to say is
that I have no objection to merging this patchset via the SELinux
tree, in principle.  If there are significant merge conflicts they
will need to be resolved first; I have no problem dealing with small
fixups as part of the merge process, but any substantial changes would
need a respin.  Also, while I haven't looked at this latest patchset,
I would still want to review it for obvious reasons, although having
discussed previous drafts in detail I don't expect to see anything
objectionable.

However, my biggest concern remains the lack of working tests; without
those this patchset doesn't get my ACK.  We need to have some basic
method of regression testing this, even if it does require IB
hardware, to have any hope of maintaining this long term.

-- 
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 v6 0/9] SELinux support for Infiniband RDMA

[Doug Ledford]

On Wed, 2017-01-25 at 02:58 -0500, Paul Moore wrote:
> On Tue, Jan 24, 2017 at 4:40 PM, Doug Ledford 
> wrote:
> > 
> > On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
> > > 
> > > On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens  > > x.co
> > > m> wrote:
> > > > 
> > > > 
> > > > On 12/13/2016 9:01 AM, Stephen Smalley wrote:
> > > > > 
> > > > > 
> > > > > For the LSM/SELinux bits,
> > > > > Acked-by: Stephen Smalley 
> > > > > 
> > > > > Note that there will be a merge conflict on classmap.h due to
> > > > > commits in
> > > > > the selinux next branch, but that should be easy to resolve.
> > > > > 
> > > > > We'll need the patches for the selinux userspace and
> > > > > refpolicy.
> > > > 
> > > > Thanks Stephen, I need to rebase the user space and do some
> > > > patch
> > > > breakup.  I'll start on that soon.
> > > 
> > > Sorry, I haven't had a chance to look at v6, but considering all
> > > our
> > > discussions on the previous versions I don't expect any issues
> > > from
> > > me.  I was hoping for some more generic hooks/controls, but that
> > > doesn't look to be possible given the nature of RDMA.  I also
> > > want to
> > > mention again the need for tests; we've talked about this in the
> > > past
> > > and while it isn't possible to run the tests without IB hardware,
> > > I
> > > would like to see us merge tests into the selinux-testsuite so
> > > that
> > > those who do have the required h/w available could run the tests.
> > > 
> > > Assuming we can sort out the SELinux userspace and and tests by
> > > the
> > > end of January, I see no reason why this couldn't go in for
> > > v4.11.
> > 
> > Daniel, can you work with people on the userspace and tests?  I'll
> > pull
> > this into a branch (I assume by Paul's and Stephen's comments that
> > they
> > expect it to go through my tree) ready to go, but hold actually
> > submitting it in the merge window until I've heard more from you
> > all
> > that userspace is ready.
> 
> I don't have a problem pulling this in via the SELinux tree, assuming
> you are okay with that Doug.  I'm just waiting to see tests for the
> selinux-testsuite first.

When I tried to apply the patchset, the conflicts started on the very
first file of the very first patch.  It can go through your tree, but I
suspect there will be lots of conflicts that way as this upcoming
release has been touching the cache area of the IB stack and so does
this code.  There might be significant SELinux conflicts too, I don't
know, but we know there are IB ones so far.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part
___
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 v6 0/9] SELinux support for Infiniband RDMA

[Paul Moore]

On Tue, Jan 24, 2017 at 4:40 PM, Doug Ledford  wrote:
> On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
>> On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens > m> wrote:
>> >
>> > On 12/13/2016 9:01 AM, Stephen Smalley wrote:
>> > >
>> > > For the LSM/SELinux bits,
>> > > Acked-by: Stephen Smalley 
>> > >
>> > > Note that there will be a merge conflict on classmap.h due to
>> > > commits in
>> > > the selinux next branch, but that should be easy to resolve.
>> > >
>> > > We'll need the patches for the selinux userspace and refpolicy.
>> >
>> > Thanks Stephen, I need to rebase the user space and do some patch
>> > breakup.  I'll start on that soon.
>>
>> Sorry, I haven't had a chance to look at v6, but considering all our
>> discussions on the previous versions I don't expect any issues from
>> me.  I was hoping for some more generic hooks/controls, but that
>> doesn't look to be possible given the nature of RDMA.  I also want to
>> mention again the need for tests; we've talked about this in the past
>> and while it isn't possible to run the tests without IB hardware, I
>> would like to see us merge tests into the selinux-testsuite so that
>> those who do have the required h/w available could run the tests.
>>
>> Assuming we can sort out the SELinux userspace and and tests by the
>> end of January, I see no reason why this couldn't go in for v4.11.
>
> Daniel, can you work with people on the userspace and tests?  I'll pull
> this into a branch (I assume by Paul's and Stephen's comments that they
> expect it to go through my tree) ready to go, but hold actually
> submitting it in the merge window until I've heard more from you all
> that userspace is ready.

I don't have a problem pulling this in via the SELinux tree, assuming
you are okay with that Doug.  I'm just waiting to see tests for the
selinux-testsuite first.

-- 
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 v6 0/9] SELinux support for Infiniband RDMA

[Doug Ledford]

On Tue, 2017-01-24 at 22:40 +, Daniel Jurgens wrote:
> On 1/24/2017 3:45 PM, Doug Ledford wrote:
> > 
> > Although it would also be helpful if you could rebase on a current
> > tree
> > (preferably my k.o/for-4.11 branch).
> > 
> Doug, I'm working on the user space patches, hope to be ready to
> submit in the next 1-2 weeks.  Do you want me to rebase now or wait
> until those are submitted?

I would suggest moving the rebase up just so I can provide you with an
upstream branch to test against with your user space stuff.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part
___
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 v6 0/9] SELinux support for Infiniband RDMA

[Daniel Jurgens]

On 1/24/2017 3:45 PM, Doug Ledford wrote:
> On Tue, 2017-01-24 at 16:40 -0500, Doug Ledford wrote:
>> On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
>>> On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens >> co
>>> m> wrote:

 On 12/13/2016 9:01 AM, Stephen Smalley wrote:
>
> For the LSM/SELinux bits,
> Acked-by: Stephen Smalley 
>
> Note that there will be a merge conflict on classmap.h due to
> commits in
> the selinux next branch, but that should be easy to resolve.
>
> We'll need the patches for the selinux userspace and refpolicy.
 Thanks Stephen, I need to rebase the user space and do some patch
 breakup.  I'll start on that soon.
>>> Sorry, I haven't had a chance to look at v6, but considering all
>>> our
>>> discussions on the previous versions I don't expect any issues from
>>> me.  I was hoping for some more generic hooks/controls, but that
>>> doesn't look to be possible given the nature of RDMA.  I also want
>>> to
>>> mention again the need for tests; we've talked about this in the
>>> past
>>> and while it isn't possible to run the tests without IB hardware, I
>>> would like to see us merge tests into the selinux-testsuite so that
>>> those who do have the required h/w available could run the tests.
>>>
>>> Assuming we can sort out the SELinux userspace and and tests by the
>>> end of January, I see no reason why this couldn't go in for v4.11.
>> Daniel, can you work with people on the userspace and tests?  I'll
>> pull
>> this into a branch (I assume by Paul's and Stephen's comments that
>> they
>> expect it to go through my tree) ready to go, but hold actually
>> submitting it in the merge window until I've heard more from you all
>> that userspace is ready.
> Although it would also be helpful if you could rebase on a current tree
> (preferably my k.o/for-4.11 branch).
>
Doug, I'm working on the user space patches, hope to be ready to submit in the 
next 1-2 weeks.  Do you want me to rebase now or wait until those are submitted?


___
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 v6 0/9] SELinux support for Infiniband RDMA

[Doug Ledford]

On Tue, 2017-01-24 at 16:40 -0500, Doug Ledford wrote:
> On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
> > 
> > On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens  > co
> > m> wrote:
> > > 
> > > 
> > > On 12/13/2016 9:01 AM, Stephen Smalley wrote:
> > > > 
> > > > 
> > > > For the LSM/SELinux bits,
> > > > Acked-by: Stephen Smalley 
> > > > 
> > > > Note that there will be a merge conflict on classmap.h due to
> > > > commits in
> > > > the selinux next branch, but that should be easy to resolve.
> > > > 
> > > > We'll need the patches for the selinux userspace and refpolicy.
> > > 
> > > Thanks Stephen, I need to rebase the user space and do some patch
> > > breakup.  I'll start on that soon.
> > 
> > Sorry, I haven't had a chance to look at v6, but considering all
> > our
> > discussions on the previous versions I don't expect any issues from
> > me.  I was hoping for some more generic hooks/controls, but that
> > doesn't look to be possible given the nature of RDMA.  I also want
> > to
> > mention again the need for tests; we've talked about this in the
> > past
> > and while it isn't possible to run the tests without IB hardware, I
> > would like to see us merge tests into the selinux-testsuite so that
> > those who do have the required h/w available could run the tests.
> > 
> > Assuming we can sort out the SELinux userspace and and tests by the
> > end of January, I see no reason why this couldn't go in for v4.11.
> 
> Daniel, can you work with people on the userspace and tests?  I'll
> pull
> this into a branch (I assume by Paul's and Stephen's comments that
> they
> expect it to go through my tree) ready to go, but hold actually
> submitting it in the merge window until I've heard more from you all
> that userspace is ready.

Although it would also be helpful if you could rebase on a current tree
(preferably my k.o/for-4.11 branch).

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part
___
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 v6 0/9] SELinux support for Infiniband RDMA

[Doug Ledford]

On Tue, 2016-12-13 at 17:17 -0500, Paul Moore wrote:
> On Tue, Dec 13, 2016 at 11:25 AM, Daniel Jurgens  m> wrote:
> > 
> > On 12/13/2016 9:01 AM, Stephen Smalley wrote:
> > > 
> > > For the LSM/SELinux bits,
> > > Acked-by: Stephen Smalley 
> > > 
> > > Note that there will be a merge conflict on classmap.h due to
> > > commits in
> > > the selinux next branch, but that should be easy to resolve.
> > > 
> > > We'll need the patches for the selinux userspace and refpolicy.
> > 
> > Thanks Stephen, I need to rebase the user space and do some patch
> > breakup.  I'll start on that soon.
> 
> Sorry, I haven't had a chance to look at v6, but considering all our
> discussions on the previous versions I don't expect any issues from
> me.  I was hoping for some more generic hooks/controls, but that
> doesn't look to be possible given the nature of RDMA.  I also want to
> mention again the need for tests; we've talked about this in the past
> and while it isn't possible to run the tests without IB hardware, I
> would like to see us merge tests into the selinux-testsuite so that
> those who do have the required h/w available could run the tests.
> 
> Assuming we can sort out the SELinux userspace and and tests by the
> end of January, I see no reason why this couldn't go in for v4.11.

Daniel, can you work with people on the userspace and tests?  I'll pull
this into a branch (I assume by Paul's and Stephen's comments that they
expect it to go through my tree) ready to go, but hold actually
submitting it in the merge window until I've heard more from you all
that userspace is ready.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part
___
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 v6 0/9] SELinux support for Infiniband RDMA

[Daniel Jurgens]

On 12/13/2016 9:01 AM, Stephen Smalley wrote:
> On 11/23/2016 09:17 AM, Dan Jurgens wrote:
>> From: Daniel Jurgens 
>>
>> Infiniband applications access HW from user-space -- traffic is generated
>> directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
>> which are associated directly with HW transport endpoints, are a natural
>> choice for enforcing granular mandatory access control for Infiniband. QPs 
>> may
>> only send or receives packets tagged with the corresponding partition key
>> (PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
>> the partition.
>>
>> Every Infiniband fabric is controlled by a central Subnet Manager (SM). The 
>> SM
>> provisions the partitions by assigning each port with the partitions it can
>> access. In addition, the SM tags each port with a subnet prefix, which
>> identifies the subnet. Determining which users are allowed to access which
>> partition keys on a given subnet forms an effective policy for isolating 
>> users
>> on the fabric. Any application that attempts to send traffic on a given 
>> subnet
>> is automatically subject to the policy, regardless of which device and port 
>> it
>> uses. SM software configures the subnet through a privileged Subnet 
>> Management
>> Interface (SMI), which is presented by each Infiniband port. Thus, the SMI 
>> must
>> also be controlled to prevent unauthorized changes to fabric configuration 
>> and
>> partitioning. 
>>
>> To support access control for IB partitions and subnet management, security
>> contexts must be provided for two new types of objects - PKeys and IB ports.
>>
>> A PKey label consists of a subnet prefix and a range of PKey values and is
>> similar to the labeling mechanism for netports. Each Infiniband port can 
>> reside
>> on a different subnet. So labeling the PKey values for specific subnet 
>> prefixes
>> provides the user maximum flexibility, as PKey values may be determined
>> independently for different subnets. There is a single access vector for 
>> PKeys
>> called "access".
>>
>> An Infiniband port is labeled by device name and port number. There is a 
>> single
>> access vector for IB ports called "manage_subnet".
>>
>> Because RDMA allows kernel bypass, enforcement must be done during connection
>> setup. Communication over RDMA requires a send and receive queue, 
>> collectively
>> known as a Queue Pair (QP). A QP must be initialized by privileged system 
>> calls
>> before it can be used to send or receive data. During initialization the user
>> must provide the PKey and port the QP will use; at this time access control 
>> can
>> be enforced.
>>
>> Because there is a possibility that the enforcement settings or security
>> policy can change, a means of notifying the ib_core module of such changes
>> is required. To facilitate this a generic notification callback mechanism
>> is added to the LSM. One callback is registered for checking the QP PKey
>> associations when the policy changes. Mad agents also register a callback,
>> they cache the permission to send and receive SMPs to avoid another per
>> packet call to the LSM.
>>
>> Because frequent accesses to the same PKey's SID is expected a cache is
>> implemented which is very similar to the netport cache.
>>
>> In order to properly enforce security when changes to the PKey table or
>> security policy or enforcement occur ib_core must track which QPs are
>> using which port, pkey index, and alternate path for every IB device.
>> This makes operations that used to be atomic transactional.
>>
>> When modifying a QP, ib_core must associate it with the PKey index, port,
>> and alternate path specified. If the QP was already associated with
>> different settings, the QP is added to the new list prior to the
>> modification. If the modify succeeds then the old listing is removed. If
>> the modify fails the new listing is removed and the old listing remains
>> unchanged.
>>
>> When destroying a QP the ib_qp structure is freed by the decive specific
>> driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
>> security related information in a separate structure. When a 'destroy'
>> request is in process the ib_qp structure is in an undefined state so if
>> there are changes to the security policy or PKey table, the security checks
>> cannot reset the QP if it doesn't have permission for the new setting. If
>> the 'destroy' fails, security for that QP must be enforced again and its
>> status in the list is restored. If the 'destroy' succeeds the security info
>> can be cleaned up and freed.
>>
>> There are a number of locks required to protect the QP security structure
>> and the QP to device/port/pkey index lists. If multiple locks are required,
>> the safe locking order is: QP security structure mutex first, followed by
>> any list locks needed, which are sorted first by port followed by pkey
>> index.
>>
>> ---
>> v2:
>> - Use void* blobs in the LSM hooks. 

Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Stephen Smalley]

On 11/23/2016 09:17 AM, Dan Jurgens wrote:
> From: Daniel Jurgens 
> 
> Infiniband applications access HW from user-space -- traffic is generated
> directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
> which are associated directly with HW transport endpoints, are a natural
> choice for enforcing granular mandatory access control for Infiniband. QPs may
> only send or receives packets tagged with the corresponding partition key
> (PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
> the partition.
> 
> Every Infiniband fabric is controlled by a central Subnet Manager (SM). The SM
> provisions the partitions by assigning each port with the partitions it can
> access. In addition, the SM tags each port with a subnet prefix, which
> identifies the subnet. Determining which users are allowed to access which
> partition keys on a given subnet forms an effective policy for isolating users
> on the fabric. Any application that attempts to send traffic on a given subnet
> is automatically subject to the policy, regardless of which device and port it
> uses. SM software configures the subnet through a privileged Subnet Management
> Interface (SMI), which is presented by each Infiniband port. Thus, the SMI 
> must
> also be controlled to prevent unauthorized changes to fabric configuration and
> partitioning. 
> 
> To support access control for IB partitions and subnet management, security
> contexts must be provided for two new types of objects - PKeys and IB ports.
> 
> A PKey label consists of a subnet prefix and a range of PKey values and is
> similar to the labeling mechanism for netports. Each Infiniband port can 
> reside
> on a different subnet. So labeling the PKey values for specific subnet 
> prefixes
> provides the user maximum flexibility, as PKey values may be determined
> independently for different subnets. There is a single access vector for PKeys
> called "access".
> 
> An Infiniband port is labeled by device name and port number. There is a 
> single
> access vector for IB ports called "manage_subnet".
> 
> Because RDMA allows kernel bypass, enforcement must be done during connection
> setup. Communication over RDMA requires a send and receive queue, collectively
> known as a Queue Pair (QP). A QP must be initialized by privileged system 
> calls
> before it can be used to send or receive data. During initialization the user
> must provide the PKey and port the QP will use; at this time access control 
> can
> be enforced.
> 
> Because there is a possibility that the enforcement settings or security
> policy can change, a means of notifying the ib_core module of such changes
> is required. To facilitate this a generic notification callback mechanism
> is added to the LSM. One callback is registered for checking the QP PKey
> associations when the policy changes. Mad agents also register a callback,
> they cache the permission to send and receive SMPs to avoid another per
> packet call to the LSM.
> 
> Because frequent accesses to the same PKey's SID is expected a cache is
> implemented which is very similar to the netport cache.
> 
> In order to properly enforce security when changes to the PKey table or
> security policy or enforcement occur ib_core must track which QPs are
> using which port, pkey index, and alternate path for every IB device.
> This makes operations that used to be atomic transactional.
> 
> When modifying a QP, ib_core must associate it with the PKey index, port,
> and alternate path specified. If the QP was already associated with
> different settings, the QP is added to the new list prior to the
> modification. If the modify succeeds then the old listing is removed. If
> the modify fails the new listing is removed and the old listing remains
> unchanged.
> 
> When destroying a QP the ib_qp structure is freed by the decive specific
> driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
> security related information in a separate structure. When a 'destroy'
> request is in process the ib_qp structure is in an undefined state so if
> there are changes to the security policy or PKey table, the security checks
> cannot reset the QP if it doesn't have permission for the new setting. If
> the 'destroy' fails, security for that QP must be enforced again and its
> status in the list is restored. If the 'destroy' succeeds the security info
> can be cleaned up and freed.
> 
> There are a number of locks required to protect the QP security structure
> and the QP to device/port/pkey index lists. If multiple locks are required,
> the safe locking order is: QP security structure mutex first, followed by
> any list locks needed, which are sorted first by port followed by pkey
> index.
> 
> ---
> v2:
> - Use void* blobs in the LSM hooks. Paul Moore
> - Make the policy change callback generic. Yuval Shaia, Paul Moore
> - Squash LSM changes into the patches where the calls are added. Paul Moore
> - 

Re: [PATCH v6 0/9] SELinux support for Infiniband RDMA

[Doug Ledford]

On 11/23/2016 9:17 AM, Dan Jurgens wrote:
> From: Daniel Jurgens 
> 
> Infiniband applications access HW from user-space -- traffic is generated
> directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
> which are associated directly with HW transport endpoints, are a natural
> choice for enforcing granular mandatory access control for Infiniband. QPs may
> only send or receives packets tagged with the corresponding partition key
> (PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
> the partition.
> 
> Every Infiniband fabric is controlled by a central Subnet Manager (SM). The SM
> provisions the partitions by assigning each port with the partitions it can
> access. In addition, the SM tags each port with a subnet prefix, which
> identifies the subnet. Determining which users are allowed to access which
> partition keys on a given subnet forms an effective policy for isolating users
> on the fabric. Any application that attempts to send traffic on a given subnet
> is automatically subject to the policy, regardless of which device and port it
> uses. SM software configures the subnet through a privileged Subnet Management
> Interface (SMI), which is presented by each Infiniband port. Thus, the SMI 
> must
> also be controlled to prevent unauthorized changes to fabric configuration and
> partitioning. 
> 
> To support access control for IB partitions and subnet management, security
> contexts must be provided for two new types of objects - PKeys and IB ports.
> 
> A PKey label consists of a subnet prefix and a range of PKey values and is
> similar to the labeling mechanism for netports. Each Infiniband port can 
> reside
> on a different subnet. So labeling the PKey values for specific subnet 
> prefixes
> provides the user maximum flexibility, as PKey values may be determined
> independently for different subnets. There is a single access vector for PKeys
> called "access".
> 
> An Infiniband port is labeled by device name and port number. There is a 
> single
> access vector for IB ports called "manage_subnet".
> 
> Because RDMA allows kernel bypass, enforcement must be done during connection
> setup. Communication over RDMA requires a send and receive queue, collectively
> known as a Queue Pair (QP). A QP must be initialized by privileged system 
> calls
> before it can be used to send or receive data. During initialization the user
> must provide the PKey and port the QP will use; at this time access control 
> can
> be enforced.
> 
> Because there is a possibility that the enforcement settings or security
> policy can change, a means of notifying the ib_core module of such changes
> is required. To facilitate this a generic notification callback mechanism
> is added to the LSM. One callback is registered for checking the QP PKey
> associations when the policy changes. Mad agents also register a callback,
> they cache the permission to send and receive SMPs to avoid another per
> packet call to the LSM.
> 
> Because frequent accesses to the same PKey's SID is expected a cache is
> implemented which is very similar to the netport cache.
> 
> In order to properly enforce security when changes to the PKey table or
> security policy or enforcement occur ib_core must track which QPs are
> using which port, pkey index, and alternate path for every IB device.
> This makes operations that used to be atomic transactional.
> 
> When modifying a QP, ib_core must associate it with the PKey index, port,
> and alternate path specified. If the QP was already associated with
> different settings, the QP is added to the new list prior to the
> modification. If the modify succeeds then the old listing is removed. If
> the modify fails the new listing is removed and the old listing remains
> unchanged.
> 
> When destroying a QP the ib_qp structure is freed by the decive specific
> driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
> security related information in a separate structure. When a 'destroy'
> request is in process the ib_qp structure is in an undefined state so if
> there are changes to the security policy or PKey table, the security checks
> cannot reset the QP if it doesn't have permission for the new setting. If
> the 'destroy' fails, security for that QP must be enforced again and its
> status in the list is restored. If the 'destroy' succeeds the security info
> can be cleaned up and freed.
> 
> There are a number of locks required to protect the QP security structure
> and the QP to device/port/pkey index lists. If multiple locks are required,
> the safe locking order is: QP security structure mutex first, followed by
> any list locks needed, which are sorted first by port followed by pkey
> index.

Ack for the IB parts.  Do we have a vote on the SELinux parts from the
security people?

> ---
> v2:
> - Use void* blobs in the LSM hooks. Paul Moore
> - Make the policy change callback generic. Yuval Shaia, Paul 

[PATCH v6 0/9] SELinux support for Infiniband RDMA

[Dan Jurgens]

From: Daniel Jurgens 

Infiniband applications access HW from user-space -- traffic is generated
directly by HW, bypassing the kernel. Consequently, Infiniband Partitions,
which are associated directly with HW transport endpoints, are a natural
choice for enforcing granular mandatory access control for Infiniband. QPs may
only send or receives packets tagged with the corresponding partition key
(PKey). The PKey is not a cryptographic key; it's a 16 bit number identifying
the partition.

Every Infiniband fabric is controlled by a central Subnet Manager (SM). The SM
provisions the partitions by assigning each port with the partitions it can
access. In addition, the SM tags each port with a subnet prefix, which
identifies the subnet. Determining which users are allowed to access which
partition keys on a given subnet forms an effective policy for isolating users
on the fabric. Any application that attempts to send traffic on a given subnet
is automatically subject to the policy, regardless of which device and port it
uses. SM software configures the subnet through a privileged Subnet Management
Interface (SMI), which is presented by each Infiniband port. Thus, the SMI must
also be controlled to prevent unauthorized changes to fabric configuration and
partitioning. 

To support access control for IB partitions and subnet management, security
contexts must be provided for two new types of objects - PKeys and IB ports.

A PKey label consists of a subnet prefix and a range of PKey values and is
similar to the labeling mechanism for netports. Each Infiniband port can reside
on a different subnet. So labeling the PKey values for specific subnet prefixes
provides the user maximum flexibility, as PKey values may be determined
independently for different subnets. There is a single access vector for PKeys
called "access".

An Infiniband port is labeled by device name and port number. There is a single
access vector for IB ports called "manage_subnet".

Because RDMA allows kernel bypass, enforcement must be done during connection
setup. Communication over RDMA requires a send and receive queue, collectively
known as a Queue Pair (QP). A QP must be initialized by privileged system calls
before it can be used to send or receive data. During initialization the user
must provide the PKey and port the QP will use; at this time access control can
be enforced.

Because there is a possibility that the enforcement settings or security
policy can change, a means of notifying the ib_core module of such changes
is required. To facilitate this a generic notification callback mechanism
is added to the LSM. One callback is registered for checking the QP PKey
associations when the policy changes. Mad agents also register a callback,
they cache the permission to send and receive SMPs to avoid another per
packet call to the LSM.

Because frequent accesses to the same PKey's SID is expected a cache is
implemented which is very similar to the netport cache.

In order to properly enforce security when changes to the PKey table or
security policy or enforcement occur ib_core must track which QPs are
using which port, pkey index, and alternate path for every IB device.
This makes operations that used to be atomic transactional.

When modifying a QP, ib_core must associate it with the PKey index, port,
and alternate path specified. If the QP was already associated with
different settings, the QP is added to the new list prior to the
modification. If the modify succeeds then the old listing is removed. If
the modify fails the new listing is removed and the old listing remains
unchanged.

When destroying a QP the ib_qp structure is freed by the decive specific
driver (i.e. mlx4_ib) if the 'destroy' is successful. This requires storing
security related information in a separate structure. When a 'destroy'
request is in process the ib_qp structure is in an undefined state so if
there are changes to the security policy or PKey table, the security checks
cannot reset the QP if it doesn't have permission for the new setting. If
the 'destroy' fails, security for that QP must be enforced again and its
status in the list is restored. If the 'destroy' succeeds the security info
can be cleaned up and freed.

There are a number of locks required to protect the QP security structure
and the QP to device/port/pkey index lists. If multiple locks are required,
the safe locking order is: QP security structure mutex first, followed by
any list locks needed, which are sorted first by port followed by pkey
index.

---
v2:
- Use void* blobs in the LSM hooks. Paul Moore
- Make the policy change callback generic. Yuval Shaia, Paul Moore
- Squash LSM changes into the patches where the calls are added. Paul Moore
- Don't add new initial SIDs. Stephen Smalley
- Squash MAD agent PKey and SMI patches and move logic to IB security. Dan 
Jurgens
- Changed ib_end_port to ib_port. Paul Moore
- Changed ib_port access vector from smp to manage_subnet.