[PATCH 05/97] LSM: Create an lsm_export data structure.

[Stephen Smalley]

On 2/28/19 5:18 PM, Casey Schaufler wrote:
> When more than one security module is exporting data to
> audit and networking sub-systems a single 32 bit integer
> is no longer sufficient to represent the data. Add a
> structure to be used instead.
> 
> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
> ---
>   include/linux/security.h | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 13537a49ae97..a79fe8ef9d84 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -73,6 +73,18 @@ enum lsm_event {
>   	LSM_POLICY_CHANGE,
>   };
>   
> +/* Data exported by the security modules */
> +struct lsm_export {
> +	u32	selinux;
> +	u32	smack;
> +	u32	apparmor;
> +	u32	flags;
> +};
> +#define LSM_EXPORT_NONE		0x00
> +#define LSM_EXPORT_SELINUX	0x01
> +#define LSM_EXPORT_SMACK	0x02
> +#define LSM_EXPORT_APPARMOR	0x04

Can this be generalized to avoid hardcoding the names of specific 
security modules in the field and symbol names?  Possibly just an array 
of secids with the indices dynamically assigned by the infrastructure at 
registration time?  We don't really want to have to patch this structure 
every time someone adds a new security module that needs audit and/or 
network facilities, right?

> +
>   /* These functions are in security/commoncap.c */
>   extern int cap_capable(const struct cred *cred, struct user_namespace *ns,
>   		       int cap, unsigned int opts);
>