Re: [PATCH 03/12] selinux: Implement Infiniband flush callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 23, 2016 at 10:52:49PM +0300, Dan Jurgens wrote:
> From: Daniel Jurgens <danielj@xxxxxxxxxxxx>
> 
> Because access for infiniband is enforced in the setup phase of a
> connection there must be a way to notify ib_core if the policy or
> enforcement setting have changed.
> 
> Added register and unregister_ib_flush_callback hooks so infiniband can
> setup notification of policy and enforment changes.  In the AVC reset

Extra space before " In"

> callback function call the ib_flush callback if it's registered. Also
> renamed the callback function, the previous name was 'net' specific.
> 
> Signed-off-by: Daniel Jurgens <danielj@xxxxxxxxxxxx>
> Reviewed-by: Eli Cohen <eli@xxxxxxxxxxxx>
> ---
>  security/selinux/hooks.c | 36 ++++++++++++++++++++++++++++++++++--
>  1 file changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index a86d537..6a8841d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -94,6 +94,9 @@
>  #include "audit.h"
>  #include "avc_ss.h"
>  
> +static void (*ib_flush_callback)(void);

Do we really want to have such ib_ prefix in security/ directory?

> +static DEFINE_MUTEX(ib_flush_mutex);
> +
>  /* SECMARK reference count */
>  static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);
>  
> @@ -159,13 +162,17 @@ static int selinux_peerlbl_enabled(void)
>  	return (selinux_policycap_alwaysnetwork || netlbl_enabled() || selinux_xfrm_enabled());
>  }
>  
> -static int selinux_netcache_avc_callback(u32 event)
> +static int selinux_cache_avc_callback(u32 event)
>  {
>  	if (event == AVC_CALLBACK_RESET) {
>  		sel_netif_flush();
>  		sel_netnode_flush();
>  		sel_netport_flush();
>  		synchronize_net();
> +		mutex_lock(&ib_flush_mutex);

Suggesting to have the lock inside the callback (unless you accept my
suggestion below)

> +		if (ib_flush_callback)
> +			ib_flush_callback();

How about some generic mechanism (such as a list) in case more
modules/drivers would like to register callbacks?
( assuming this is no longer RFC :) )

> +		mutex_unlock(&ib_flush_mutex);
>  	}
>  	return 0;
>  }
> @@ -5993,6 +6000,23 @@ static int selinux_key_getsecurity(struct key *key, char **_buffer)
>  
>  #endif
>  
> +#ifdef CONFIG_SECURITY_INFINIBAND
> +static void selinux_register_ib_flush_callback(void (*callback)(void))
> +{
> +	mutex_lock(&ib_flush_mutex);
> +	ib_flush_callback = callback;
> +	mutex_unlock(&ib_flush_mutex);
> +}
> +
> +static void selinux_unregister_ib_flush_callback(void)
> +{
> +	mutex_lock(&ib_flush_mutex);
> +	ib_flush_callback = NULL;
> +	mutex_unlock(&ib_flush_mutex);
> +}
> +
> +#endif
> +
>  static struct security_hook_list selinux_hooks[] = {
>  	LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),
>  	LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),
> @@ -6174,6 +6198,12 @@ static struct security_hook_list selinux_hooks[] = {
>  	LSM_HOOK_INIT(tun_dev_attach_queue, selinux_tun_dev_attach_queue),
>  	LSM_HOOK_INIT(tun_dev_attach, selinux_tun_dev_attach),
>  	LSM_HOOK_INIT(tun_dev_open, selinux_tun_dev_open),
> +#ifdef CONFIG_SECURITY_INFINIBAND
> +	LSM_HOOK_INIT(register_ib_flush_callback,
> +		      selinux_register_ib_flush_callback),
> +	LSM_HOOK_INIT(unregister_ib_flush_callback,
> +		      selinux_unregister_ib_flush_callback),
> +#endif
>  
>  #ifdef CONFIG_SECURITY_NETWORK_XFRM
>  	LSM_HOOK_INIT(xfrm_policy_alloc_security, selinux_xfrm_policy_alloc),
> @@ -6233,9 +6263,11 @@ static __init int selinux_init(void)
>  					    0, SLAB_PANIC, NULL);
>  	avc_init();
>  
> +	ib_flush_callback = NULL;
> +
>  	security_add_hooks(selinux_hooks, ARRAY_SIZE(selinux_hooks));
>  
> -	if (avc_add_callback(selinux_netcache_avc_callback, AVC_CALLBACK_RESET))
> +	if (avc_add_callback(selinux_cache_avc_callback, AVC_CALLBACK_RESET))
>  		panic("SELinux: Unable to register AVC netcache callback\n");
>  
>  	if (selinux_enforcing)
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______________________________________________
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.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux