On 6/30/2016 4:27 PM, Paul Moore wrote:
> On Thu, Jun 30, 2016 at 5:09 PM, Daniel Jurgens <[email protected]> wrote:
>> On 6/30/2016 3:28 PM, Paul Moore wrote:
>>> On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens <[email protected]> wrote:
>>>> From: Daniel Jurgens <[email protected]>
>>>>
>>>> Add nine new hooks
>>>>  1. Allocate security contexts for Infiniband QPs.
>>>>  2. Free security contexts for Infiniband QPs.
>>>>  3. Allocate security contexts for Infiniband MAD agents.
>>>>  4. Free security contexts for Infiniband MAD agents.
>>>>  5. Enforce QP access to Pkeys
>>>>  6. Enforce MAD agent access to Pkeys
>>>>  7. Enforce MAD agent access to Infiniband End Ports for sending Subnet
>>>>     Management Packets (SMP)
>>>>  8. A hook to register a callback to receive notifications of
>>>>     security policy or enforcement changes.  Restricting a QPs access to
>>>>     a pkey will be done during setup and not on a per packet basis
>>>>     access must be enforced again.
>>>>  9. A hook to unregister the callback.
>>>>
>>>> Signed-off-by: Daniel Jurgens <[email protected]>
>>>> Reviewed-by: Eli Cohen <[email protected]>
>>>> ---
>>>>  include/linux/lsm_hooks.h | 71 ++++++++++++++++++++++++++++++++++++++++
>>>>  include/linux/security.h  | 63 +++++++++++++++++++++++++++++++++++
>>>>  include/rdma/ib_verbs.h   |  4 +++
>>>>  security/Kconfig          |  9 +++++
>>>>  security/security.c       | 83 
>>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>>  5 files changed, 230 insertions(+)
>>> I'd recommend putting the IB hook calls into this patch as well, it
>>> helps make the hooks a bit more concrete as you can see where, and how
>>> they are called.
>> Do you mean add them with SELinux hook implementations?  Or with the the 
>> IB/Core code where they are called?
> I mean the IB changes.  That way a single patch has both the hook
> declarations and their calling locations; it helps make the hooks a
> bit less abstract.
>
> The SELinux hook implementations should be kept separate.
>
>> I tried as best as I could to avoid mingling LSM, IB/Core, and SELinux 
>> changes.  Hoping to minimize the burden of a single patch needing acceptance 
>> from multiple maintainers and synchronization problems that could create.  I 
>> could split this up and add the hooks where they are actually used if you 
>> don't think that's problem though.
> Ultimately the entire patchset needs to get acceptance from the IB and
> SELinux folks, with no objections from any of the other LSM
> maintainers.  My guess is, I'll probably be the one who ends up
> merging this as it's more SELinux than anything else, but I'll want a
> thumbs-up/ACK from the IB folks before I do that.
OK, I can split this patch up and squash to the respective IB core patches 
where they are first used.

_______________________________________________
Selinux mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to [email protected].

Reply via email to