On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens <danielj@xxxxxxxxxxxx> wrote: > From: Daniel Jurgens <danielj@xxxxxxxxxxxx> > > This patch series was submitted previously as an RFC. The 3rd version was > posted on 19 Apr 2016 with the subject "[RFC PATCH v3 NN/MM] SELinux support > for Infiniband RDMA". Hi Dan, Thanks for sticking with this patchset, I'm working through it right now and I have a question on the overall design (below). > Because RDMA allows for kernel bypass all enforcement must be done during > connection setup. To communicate over RDMA requires a send and receive queue > called a queue pair (QP). During the creation of a QP it is initialized > 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 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 two LSM hooks are provided, ib_core will > register and unregister a callback function at init and cleanup respectively. > SELinux will call the callback as appropriate if it has been registered. > When the callback is called ib_core will recheck the PKey access for all > existing QPs. ... > 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 > each 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 modify attempt. 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 hardware driver > 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 restored. > If the destroy succeeds the security info can be cleaned up and freed. Perhaps I'll end up answering this for myself as I work my way through the patches, but hopefully you are handling the case where a destroy operation fails and the QP needs to be revalidated? I'm also wondering if QP revalidation on a security policy change is worth the trouble; we've historically not been able to provide any revoke guarantees so I'm not sure if it is worth a lot of added complexity to gain this functionality just for Infiniband. That said, it would be *nice* to have revalidation/revocation working, even if only for IB. It may be that we need similar code to handle the various corner cases, so we may be stuck with the complexity anyway, I just thought it was worth bringing up as a topic of discussion. -- paul moore www.paul-moore.com _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
