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

[Casey Schaufler]

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

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);
>>
>