[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1873242bbd8.28e3.85c95baa4474aabc7814e68940a78392@paul-moore.com>
Date: Thu, 30 Mar 2023 07:24:19 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
CC: <linux-security-module@...r.kernel.org>, <jmorris@...ei.org>,
<keescook@...omium.org>, <john.johansen@...onical.com>,
<penguin-kernel@...ove.sakura.ne.jp>,
<stephen.smalley.work@...il.com>, <linux-kernel@...r.kernel.org>,
<linux-api@...r.kernel.org>, <mic@...ikod.net>
Subject: Re: [PATCH v7 04/11] LSM: syscalls for current process attributes
On March 29, 2023 9:12:19 PM Paul Moore <paul@...l-moore.com> wrote:
> On Wed, Mar 15, 2023 at 6:48 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
...
>
>> +/**
>> + * security_setselfattr - Set an LSM attribute on the current process.
>> + * @attr: which attribute to set
>> + * @ctx: the user-space source for the information
>> + * @size: the size of the data
>> + * @flags: reserved for future use, must be 0
>> + *
>> + * Set an LSM attribute for the current process. The LSM, attribute
>> + * and new value are included in @ctx.
>> + *
>> + * Returns 0 on success, an LSM specific value on failure.
>> + */
>> +int security_setselfattr(unsigned int __user attr, struct lsm_ctx __user *ctx,
>> + size_t __user size, u32 __user flags)
>> +{
>> + struct security_hook_list *hp;
>> + struct lsm_ctx lctx;
>
> Shouldn't we check @attr for valid values and return -EINVAL if bogus?
>
>> + if (flags != 0)
>> + return -EINVAL;
>> + if (size < sizeof(*ctx))
>> + return -EINVAL;
>
> If we're only going to support on 'lsm_ctx' entry in this function we
> should verify that the 'len' and 'ctx_len' fields are sane. Although
> more on this below ...
>
>> + if (copy_from_user(&lctx, ctx, sizeof(*ctx)))
>> + return -EFAULT;
>> +
>> + hlist_for_each_entry(hp, &security_hook_heads.setselfattr, list)
>> + if ((hp->lsmid->id) == lctx.id)
>> + return hp->hook.setselfattr(attr, ctx, size, flags);
>
> Can anyone think of any good reason why we shouldn't support setting
> multiple LSMs in one call, similar to what we do with
> security_getselfattr()? It seems like it might be a nice thing to
> have ...
Scratch that, I just reminded myself why attempting to set an attribute on
multiple LSMs in one operation would be a nightmare. Sorry about the confusion.
--
paul-moore.com
Powered by blists - more mailing lists