* [PATCH v6 0/9] SELinux support for Infiniband RDMA [not found] <1479910651-43246-1-git-send-email-danielj@mellanox.com> @ 2017-05-03 14:41 ` Paul Moore 2017-05-03 19:45 ` Daniel Jurgens 0 siblings, 1 reply; 4+ messages in thread From: Paul Moore @ 2017-05-03 14:41 UTC (permalink / raw) To: linux-security-module On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens <danielj@mellanox.com> wrote: > From: Daniel Jurgens <danielj@mellanox.com> > > 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, and selinux-testsuite patches. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v6 0/9] SELinux support for Infiniband RDMA 2017-05-03 14:41 ` [PATCH v6 0/9] SELinux support for Infiniband RDMA Paul Moore @ 2017-05-03 19:45 ` Daniel Jurgens 2017-05-04 15:51 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Daniel Jurgens @ 2017-05-03 19:45 UTC (permalink / raw) To: linux-security-module On 5/3/2017 9:41 AM, Paul Moore wrote: > On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens <danielj@mellanox.com> wrote: >> From: Daniel Jurgens <danielj@mellanox.com> >> >> 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, 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. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v6 0/9] SELinux support for Infiniband RDMA 2017-05-03 19:45 ` Daniel Jurgens @ 2017-05-04 15:51 ` Paul Moore 2017-05-17 21:23 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Paul Moore @ 2017-05-04 15:51 UTC (permalink / raw) To: linux-security-module On Wed, May 3, 2017 at 3:45 PM, Daniel Jurgens <danielj@mellanox.com> wrote: > On 5/3/2017 9:41 AM, Paul Moore wrote: >> On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens <danielj@mellanox.com> wrote: >>> From: Daniel Jurgens <danielj@mellanox.com> >>> >>> 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. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v6 0/9] SELinux support for Infiniband RDMA 2017-05-04 15:51 ` Paul Moore @ 2017-05-17 21:23 ` Paul Moore 0 siblings, 0 replies; 4+ messages in thread From: Paul Moore @ 2017-05-17 21:23 UTC (permalink / raw) To: linux-security-module On Thu, May 4, 2017 at 11:51 AM, Paul Moore <paul@paul-moore.com> wrote: > On Wed, May 3, 2017 at 3:45 PM, Daniel Jurgens <danielj@mellanox.com> wrote: >> On 5/3/2017 9:41 AM, Paul Moore wrote: >>> On Wed, Nov 23, 2016 at 9:17 AM, Dan Jurgens <danielj@mellanox.com> wrote: >>>> From: Daniel Jurgens <danielj@mellanox.com> >>>> >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-17 21:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1479910651-43246-1-git-send-email-danielj@mellanox.com>
2017-05-03 14:41 ` [PATCH v6 0/9] SELinux support for Infiniband RDMA Paul Moore
2017-05-03 19:45 ` Daniel Jurgens
2017-05-04 15:51 ` Paul Moore
2017-05-17 21:23 ` Paul Moore
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).