[Non-DoD Source] [PATCH 03/11] LSM: Manage file security blobs

[Casey Schaufler]

On 8/31/2017 8:47 AM, Stephen Smalley wrote:
> On Tue, 2017-08-29 at 13:57 -0700, Casey Schaufler wrote:
>> Subject: [PATCH 03/11] LSM: Manage file security blobs
>>
>> Move the management of file security blobs from the individual
>> security modules to the security infrastructure. The security modules
>> using file blobs have been updated accordingly. Modules are required
>> to identify the space they need at module initialization. In some
>> cases a module no longer needs to supply a blob management hook, in
>> which case the hook has been removed.
>>
>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>

<SNIP>

>>  /**
>>   * selinux_secmark_enabled - Check to see if SECMARK is currently
>> enabled
>> @@ -359,27 +358,15 @@ static void inode_free_security(struct inode
>> *inode)
>>  
>>  static int file_alloc_security(struct file *file)
>>  {
>> -	struct file_security_struct *fsec;
>> +	struct file_security_struct *fsec = selinux_file(file);
>>  	u32 sid = current_sid();
>>  
>> -	fsec = kmem_cache_zalloc(file_security_cache, GFP_KERNEL);
>> -	if (!fsec)
>> -		return -ENOMEM;
>> -
> NAK. See commit 63205654c0e05e5ffa1c6eef2fbef21dcabd2185 for why this
> was changed from a simple kzalloc() to using its own cache; we don't
> want to regress in this regard.

I was somewhat expecting this. Is there any reason that using
kmem_cache_zalloc() in the infrastructure would not address the
issue? If this is a win for SELinux it should be a win for any
module that uses file blobs.

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