Re: [PATCH 09/37] Security: Allow kernel services to override LSM settings for task actions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- David Howells <dhowells@xxxxxxxxxx> wrote:

> Allow kernel services to override LSM settings appropriate to the actions
> performed by a task by duplicating a security record, modifying it and then
> using task_struct::act_as to point to it when performing operations on behalf
> of a task.
> 
> This is used, for example, by CacheFiles which has to transparently access
> the
> cache on behalf of a process that thinks it is doing, say, NFS accesses with
> a
> potentially inappropriate (with respect to accessing the cache) set of
> security data.
> 
> This patch provides two LSM hooks for modifying a task security record:
> 
>  (*) security_kernel_act_as() which allows modification of the security datum
>      with which a task acts on other objects (most notably files).
> 
>  (*) security_create_files_as() which allows modification of the security
>      datum that is used to initialise the security data on a file that a task
>      creates.
> 
> ...

> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -976,6 +976,36 @@ static int smack_task_dup_security(struct task_security
> *sec)
>  }
>  
>  /**
> + * smack_task_kernel_act_as - Set the subjective context in a security
> record
> + * @p points to the task that nominated @secid.
> + * @sec points to the task security record to be modified.
> + * @secid specifies the security ID to be set
> + *
> + * Set the security data for a kernel service.
> + */
> +static int smack_task_kernel_act_as(struct task_struct *p,
> +				    struct task_security *sec, u32 secid)
> +{
> +	return -ENOTSUPP;
> +}
> +
> +/**
> + * smack_task_create_files_as - Set the file creation label in a security
> record
> + * @p points to the task that nominated @inode.
> + * @sec points to the task security record to be modified.
> + * @inode points to the inode to use as a reference.
> + *
> + * Set the file creation context in a security record to the same as the
> + * objective context of the specified inode
> + */
> +static int smack_task_create_files_as(struct task_struct *p,
> +				      struct task_security *sec,
> +				      struct inode *inode)
> +{
> +	return -ENOTSUPP;
> +}

Hum. ENOTSUPP is not not very satisfying, is it? I will have to
think on this a bit.

> +
> +/**
>   * smack_task_setpgid - Smack check on setting pgid
>   * @p: the task object
>   * @pgid: unused
> @@ -2444,6 +2474,8 @@ static struct security_operations smack_ops = {
>  	.task_alloc_security = 		smack_task_alloc_security,
>  	.task_free_security = 		smack_task_free_security,
>  	.task_dup_security =		smack_task_dup_security,
> +	.task_kernel_act_as =		smack_task_kernel_act_as,
> +	.task_create_files_as =		smack_task_create_files_as,
>  	.task_post_setuid =		cap_task_post_setuid,
>  	.task_setpgid = 		smack_task_setpgid,
>  	.task_getpgid = 		smack_task_getpgid,

Except for the fact that the hooks don't do anything this
looks fine. I'm not sure that I would want these hooks to
do anything, it requires additional thought to determine if
there is a good behavior for them.

Thank you.


Casey Schaufler
casey@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux