From: Daniel Durning Added a permission check to pidfd_info(). Originally, process info could be retrieved with a pidfd even if proc was mounted with hidepid enabled, allowing pidfds to be used to bypass those protections. We now call ptrace_may_access() to perform some DAC checking as well as call the appropriate LSM hook. The downside to this approach is that there are now more restrictions on accessing this info from a pidfd than when just using proc (without hidepid). I am open to suggestions if anyone can think of a better way to handle this. I have also noticed that it is possible to use pidfds to poll on any process regardless of whether the process is a child of the caller, has a different UID, or has a different security context. Is this also worth addressing? If so, what exactly should the DAC checks be? Signed-off-by: Daniel Durning --- fs/pidfs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pidfs.c b/fs/pidfs.c index dba703d4ce4a..058a7d798bca 100644 --- a/fs/pidfs.c +++ b/fs/pidfs.c @@ -365,6 +365,13 @@ static long pidfd_info(struct file *file, unsigned int cmd, unsigned long arg) goto copy_out; } + /* + * Do a filesystem cred ptrace check to verify access + * to the task's info. + */ + if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)) + return -EACCES; + c = get_task_cred(task); if (!c) return -ESRCH; -- 2.52.0