Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Mon, Jan 16, 2017 at 9:15 AM, Djalal Harouni [off-list ref] wrote:

Cc linux-api

On Mon, Jan 16, 2017 at 2:23 PM, Djalal Harouni [off-list ref] wrote:

quoted

From: Djalal Harouni <redacted>

This adds a new per-task hidepid= flag that is honored by procfs when
presenting /proc to the user, in addition to the existing hidepid= mount
option. So far, hidepid= was exclusively a per-pidns setting. Locking
down a set of processes so that they cannot see other user's processes
without affecting the rest of the system thus currently requires
creation of a private PID namespace, with all the complexity it brings,
including maintaining a stub init process as PID 1 and losing the
ability to see processes of the same user on the rest of the system.

With this patch all acesss and visibility checks in procfs now
honour two fields:

        a) the existing hide_pid field in the PID namespace
        b) the new hide_pid in struct task_struct

Access/visibility is only granted if both fields permit it; the more
restrictive one wins. By default the new task_struct hide_pid value
defaults to 0, which means behaviour is not changed from the status quo.

Setting the per-process hide_pid value is done via a new PR_SET_HIDEPID
prctl() option which takes the same three supported values as the
hidepid= mount option. The per-process hide_pid may only be increased,
never decreased, thus ensuring that once applied, processes can never
escape such a hide_pid jail.  When a process forks it inherits its
parent's hide_pid value.

Suggested usecase: let's say nginx runs as user "www-data". After
dropping privileges it may now call:

        …
        prctl(PR_SET_HIDEPID, 2);
        …

And from that point on neither nginx itself, nor any of its child
processes may see processes in /proc anymore that belong to a different
user than "www-data". Other services running on the same system remain
unaffected.

What affect, if any, does this have on ptrace() permissions?

Also, this one-way thing seems wrong to me.  I think it should roughly
follow the no_new_privs rules instead.  IOW, if you unshare your
pidns, it gets cleared.  Also, maybe you shouldn't be able to set it
without either having CAP_SYS_ADMIN over your userns or having
no_new_privs set.

--Andy