--- David Howells <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
