Re: [PATCH v6 1/3] LSM: Add /sys/kernel/security/lsm

[Casey Schaufler]

On 11/1/2016 5:53 AM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> diff --git a/security/security.c b/security/security.c
>> index f825304..f0a802ee 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -32,6 +32,7 @@
>>  /* Maximum number of letters for an LSM name string */
>>  #define SECURITY_NAME_MAX	10
>>  
>> +char *lsm_names;
>>  /* Boot-time LSM user choice */
>>  static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
>>  	CONFIG_DEFAULT_SECURITY;
>> @@ -78,6 +79,22 @@ static int __init choose_lsm(char *str)
>>  }
>>  __setup("security=", choose_lsm);
>>  
>> +static int lsm_append(char *new, char **result)
>> +{
>> +	char *cp;
>> +
>> +	if (*result == NULL) {
>> +		*result = kstrdup(new, GFP_KERNEL);
>> +	} else {
>> +		cp = kasprintf(GFP_KERNEL, "%s,%s", *result, new);
>> +		if (cp == NULL)
>> +			return -ENOMEM;
>> +		kfree(*result);
>> +		*result = cp;
>> +	}
>> +	return 0;
>> +}
>> +
> I didn't check past discussion, but how do you handle security_delete_hooks()
> case (I mean, "selinux" will remain there when reading /sys/kernel/security/lsm
> even after it is disabled at runtime)?

Paul Moore says that SELinux is going to remove the ability
to delete itself in the near future. Since that's the only
module that allows deletion I don't see that it's an issue.

> I think holding module name as one of
> "union security_list_options" members will avoid memory allocation handling
> and simplify things.

I don't see how that would simplify things, and the memory
allocation handling here is pretty basic.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>