On 6/30/2016 2:52 PM, Paul Moore wrote: > I'm still working on understanding IB, but my current thinking is very > similar to Yuval's suggestions. There is a risk of creating a general > purpose mechanism to solve a specific, isolated problem, but adding a > LSM notification mechanism does seem like a reasonable thing to do. > > My current thinking is to have the LSM framework itself, e.g. > security/security.c, maintain a list of callbacks (BTW, please make it > a RCU protected list) with other non-LSM subsystems registering > callbacks, and specific LSMs making notification calls into the LSM > framework itself which would handle iterating through the registered > callbacks. Since we're going down the general purpose solution route, > I might add an event field and a void pointer to the callback, for > example: > > void lsm_notifier_callback(unsigned int event, void *ptr); > > ... I would expect at first we would only have a POLICY_CHANGE event > (ptr set to NULL), but we may want/need to add other events in the > future. > > Make sense? Yes, I think so. I'll make this change. _______________________________________________ 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.
