Re: [PATCH] lsm_audit: use get_task_comm

[Paul Moore]

On Tue, Aug 29, 2017 at 1:06 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> On 2017-08-28 17:54, Paul Moore wrote:
>> On Mon, Aug 28, 2017 at 9:58 AM, Geliang Tang <geliangtang@xxxxxxxxx> wrote:
>> > get_task_comm() copys the task's comm under the task_lock, it's safer
>> > than directly using memcpy().
>> >
>> > Signed-off-by: Geliang Tang <geliangtang@xxxxxxxxx>
>> > ---
>> >  security/lsm_audit.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/security/lsm_audit.c b/security/lsm_audit.c
>> > index 28d4c3a..555b1c4 100644
>> > --- a/security/lsm_audit.c
>> > +++ b/security/lsm_audit.c
>> > @@ -221,7 +221,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
>> >         BUILD_BUG_ON(sizeof(a->u) > sizeof(void *)*2);
>> >
>> >         audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
>> > -       audit_log_untrustedstring(ab, memcpy(comm, current->comm, sizeof(comm)));
>> > +       audit_log_untrustedstring(ab, get_task_comm(comm, current));
>> >
>> >         switch (a->type) {
>> >         case LSM_AUDIT_DATA_NONE:
>> > @@ -312,7 +312,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
>> >                                 char comm[sizeof(tsk->comm)];
>> >                                 audit_log_format(ab, " opid=%d ocomm=", pid);
>> >                                 audit_log_untrustedstring(ab,
>> > -                                   memcpy(comm, tsk->comm, sizeof(comm)));
>> > +                                   get_task_comm(comm, tsk));
>>
>> [NOTE: adding the linux-audit mailing list to this thread]
>
> There was previously pushback about using get_task_comm() with its
> locking, which is why in this particular location, a memcpy was chosen
> instead.
>
> This was done in:
> 5deeb5cece3f9b30c8129786726b9d02c412c8ca rgb 2015-04-14
> ("lsm: copy comm before calling audit_log to avoid race in string printing")
>
> From that commit:
>     Using get_task_comm() to get a copy while acquiring the task_lock to prevent
>     this and to prevent the result from being a mixture of old and new values of
>     comm would incur potentially unacceptable overhead, considering that the value
>     can be influenced by userspace and therefore untrusted anyways.
>

Ah ha!  Thanks for that, I had a hunch this had come up before and the
locking was an issue, I just couldn't find it while searching quickly
yesterday.

So yes, NACK to this patch.

-- 
paul moore
www.paul-moore.com