linux-kernel - Re: [PATCH] connector: report comm change event when modifying /proc/pid/task/tid/comm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Sep 2019 22:10:08 +0100
From:   Will Deacon <will@...nel.org>
To:     KeMeng Shi <shikemeng@...wei.com>
Cc:     akpm@...ux-foundation.org, james.morris@...rosoft.com,
        gregkh@...uxfoundation.org, mortonm@...omium.org,
        will.deacon@....com, kristina.martsenko@....com,
        yuehaibing@...wei.com, malat@...ian.org, j.neuschaefer@....net,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] connector: report comm change event when modifying
 /proc/pid/task/tid/comm

On Mon, Sep 16, 2019 at 10:13:41AM -0400, KeMeng Shi wrote:
> Commit f786ecba41588 ("connector: add comm change event report to proc
>  connector") added proc_comm_connector to report comm change event, and
> prctl will report comm change event when dealing with PR_SET_NAME case.
> 
> prctl can only set the name of the calling thread. In order to set the name
> of other threads in a process, modifying /proc/self/task/tid/comm is a
> general way.It's exactly how pthread_setname_np do to set name of a thread.
> 
> It's unable to get comm change event of thread if the name of thread is set
> by other thread via pthread_setname_np. This update provides a chance for
> application to monitor and control threads whose name is set by other
> threads.
> 
> Signed-off-by: KeMeng Shi <shikemeng@...wei.com>
> ---
>  fs/proc/base.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index ebea9501afb8..34ffe572ac69 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -94,6 +94,7 @@
>  #include <linux/sched/debug.h>
>  #include <linux/sched/stat.h>
>  #include <linux/posix-timers.h>
> +#include <linux/cn_proc.h>
>  #include <trace/events/oom.h>
>  #include "internal.h"
>  #include "fd.h"
> @@ -1549,10 +1550,12 @@ static ssize_t comm_write(struct file *file, const char __user *buf,
>  	if (!p)
>  		return -ESRCH;
>  
> -	if (same_thread_group(current, p))
> +	if (same_thread_group(current, p)) {
>  		set_task_comm(p, buffer);
> -	else
> +		proc_comm_connector(p);
> +	} else {
>  		count = -EINVAL;
> +	}
>  
>  	put_task_struct(p);

The rough idea looks ok to me but I have two concerns:

  (1) This looks like it will be visible to userspace, and this changes
      the behaviour after ~8 years of not reporting this event.

  (2) What prevents proc_comm_connector(p) running concurrently with itself
      via the prctl()? The locking seems to be confined to set_task_comm().

Will