Re: Leaking path for set_task_comm

2018-09-28 Thread Alan Cox
> Trying to depend on task name for anything security sensitive is at > _really_ bad idea, so it seems unlikely that a LSM would want to > protect the process name. (And if they did, the first thing I would > ask is "Why? What are you trying to do? Do you realize how many > *other* ways the pr

Re: Leaking path for set_task_comm

2018-09-25 Thread Theodore Y. Ts'o
On Tue, Sep 25, 2018 at 08:44:39PM -0400, TongZhang wrote: > Yes, this is exactly what I am saying. > A process can change its own name using prctl or /proc/self/comm. > prctl is protected by security_task_prctl, whereas /proc/self/comm is not > protected by this LSM hook. > > A system admin may

Re: Leaking path for set_task_comm

2018-09-25 Thread TongZhang
Yes, this is exactly what I am saying. A process can change its own name using prctl or /proc/self/comm. prctl is protected by security_task_prctl, whereas /proc/self/comm is not protected by this LSM hook. A system admin may expect to use security_task_prctl to block all attempt to change proce

Re: Leaking path for set_task_comm

2018-09-25 Thread Cyrill Gorcunov
On Tue, Sep 25, 2018 at 01:27:08PM -0400, Tong Zhang wrote: > Kernel Version: 4.18.5 > > Problem Description: > > When using prctl(PR_SET_NAME) to set the thread name, it is checked by > security_task_prctl. > > We discovered a leaking path that can also use method implemented in > fs/proc/bas

Leaking path for set_task_comm

2018-09-25 Thread Tong Zhang
Kernel Version: 4.18.5 Problem Description: When using prctl(PR_SET_NAME) to set the thread name, it is checked by security_task_prctl. We discovered a leaking path that can also use method implemented in fs/proc/base.c:1526 comm_write(), to do similar thing without asking LSM’s decision. -