Thread (2 messages) 2 messages, 2 authors, 2016-07-22

Re: [PATCH v2 3/9] selinux lsm IB/core: Implement LSM notification system

flat view

From: Daniel Jurgens <hidden>
Date: 2016-07-22 16:50:51
Also in: selinux

On 7/22/2016 11:21 AM, Paul Moore wrote:
On Thu, Jul 14, 2016 at 6:56 PM, Dan Jurgens [off-list ref] wrote:
quoted
v2:
- new patch that has the generic notification, replaces selinux and
  IB/core patches related to the ib_flush callback. Yuval Shaia and Paul
  Moore
---
 drivers/infiniband/core/device.c |   46 ++++++++++++++++++++++++++++++
 include/linux/security.h         |   10 ++++++
 security/security.c              |   58 ++++++++++++++++++++++++++++++++++++++
 security/selinux/hooks.c         |    5 ++-
 security/selinux/selinuxfs.c     |    2 +
 5 files changed, 119 insertions(+), 2 deletions(-)
Thanks for making this more generic.  I've got some comments below,
but in the course of reviewing this I realized that the kernel has an
existing, general purpose notifier mechanism (see
include/linux/notifier.h); while I've seen the notifier code in the
network stack, I never realized it was created as a general purpose
mechanism.  My apologies, I should have noticed this earlier and
mentioned it.

As far as how that impacts this patch; it seems like we should be good
citizens and use the general mechanism, I don't see any obvious
reasons why it wouldn't work.  That said, I do feel bad for not
realizing this earlier.  If it isn't too annoying, would you mind
updating this patch *again*?
Sure, I'll can do that for v3.
quoted
+
+static LIST_HEAD(lsm_notifier_list);
+static DEFINE_SPINLOCK(lsm_notifier_lock);
+static u32 next_callback_id;
I'd rather see the callback ID named something that makes it obvious
it is tied to the lsm_notifier_* bits, perhaps lsm_notifier_nextid?
I think this will go away with the switch to the generic notification, but if it stays I'll make the change.
quoted
 /* Boot-time LSM user choice */
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
        CONFIG_DEFAULT_SECURITY;
@@ -98,6 +110,52 @@ int __init security_module_enable(const char *module)
        return !strcmp(module, chosen_lsm);
 }

+void security_lsm_notify(enum lsm_event event, void *data)
+{
+       struct lsm_notifier_entry *entry;
+
+       rcu_read_lock();
+       list_for_each_entry_rcu(entry, &lsm_notifier_list, list)
+               entry->func(event, entry->ctx, data);
+       rcu_read_unlock();
+}
+EXPORT_SYMBOL(security_lsm_notify);
+
+int security_register_lsm_notifier(lsm_notifier func, void *ctx, u32 *id)
+{
+       struct lsm_notifier_entry *entry;
+
+       entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+       if (!entry)
+               return -ENOMEM;
+
+       entry->func = func;
+       entry->ctx = ctx;
Do we need ctx?  We do need to ability to pass a blob to the callback
which will vary based on the event, but I'm not sure the ctx here has
much value.
You'll see how I used ctx in "[PATCH v2 4/9] IB/core: Enforce security on management datagrams".  Many mad agents can be created and each will register for a callback.  I used the context to store a pointer to the specific mad agent.
quoted
+       spin_lock(&lsm_notifier_lock);
+       entry->callback_id = next_callback_id++;
+       *id = entry->callback_id;
+       list_add_rcu(&entry->list, &lsm_notifier_list);
+       spin_unlock(&lsm_notifier_lock);
+
+       return 0;
+}
+EXPORT_SYMBOL(security_register_lsm_notifier);


_______________________________________________
Selinux mailing list
Selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org
To unsubscribe, send email to Selinux-leave-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
To get help, send an email containing "help" to Selinux-request-+05T5uksL2pAGbPMOrvdOA@public.gmane.org
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help