diff mbox series

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

Message ID 20190228221933.2551-6-casey@schaufler-ca.com (mailing list archive)
State New, archived
Headers show
Series LSM: Complete module stacking | expand

Commit Message

Casey Schaufler Feb. 28, 2019, 10:18 p.m. UTC
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@schaufler-ca.com>
---
 include/linux/security.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Stephen Smalley March 1, 2019, 2 p.m. UTC | #1
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@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);
>
Casey Schaufler March 1, 2019, 4:46 p.m. UTC | #2
On 3/1/2019 6:00 AM, Stephen Smalley wrote:
> 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@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?

Yes, it can. I considered doing so very seriously. The reason
not to do it is data lifecycle management. In today's code secids
are often allocated on the stack and passed to code that holds the
value indefinitely. If every assignment became an allocate and copy
operation there would have to be reference counting and a lot more
intelligence.

The other advantage to the scheme used here is that an lsm_export
can include something other than a secid should a security module
so choose. It's not in this set, but I plan to change the Smack
entry from a u32 to a struct smack_known *, making several operations
much more efficient. Of course, that could be done using blob
management, but the complexity increases yet again.

> 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?

It's not a design that is being proposed without consideration.
I seem to recall hearing the lifecycle arguments as a primary
rationale for secids more than once.

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

Patch

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
+
 /* These functions are in security/commoncap.c */
 extern int cap_capable(const struct cred *cred, struct user_namespace *ns,
 		       int cap, unsigned int opts);