On Tue, Aug 29, 2017 at 1:06 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2017-08-28 17:54, Paul Moore wrote:
> On Mon, Aug 28, 2017 at 9:58 AM, Geliang Tang <geliangtang(a)gmail.com> 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(a)gmail.com>
> > ---
> > 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