On 6/29/2016 12:33 PM, Paul Moore wrote: > On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens <dani...@mellanox.com> wrote: >> 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?
Yes, if the destroy fails the security is checked again. You can see this in security.c ib_destroy_qp_security_abort which is added in "[PATCH 09/12] IB/core: Enforce PKey security on QPs" > 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. QP re-validation on policy change comes cheap because it's possible for the PKey table to change. So a mechanism to recheck all the QPs is needed regardless. I'd be fine with getting rid of it if you think that's best. In a production environment SELinux will always be enforcing so it's probably not really needed. During my testing it left a funny taste in my mouth when I had QPs that shouldn't be allowed continue to exist after setenforce 1. On the other hand I'm not in love with the callback registration for policy change notification one off for Infiniband. In on of the RFCs I used an LSM hook that ib/core would implement. I think Casey commented on that, so I changed it to what you see now. Thank you for reviewing this. _______________________________________________ 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.
