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

[Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>]

On Mon, Jan 16, 2017 at 9:15 AM, Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Cc linux-api
>
> On Mon, Jan 16, 2017 at 2:23 PM, Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> From: Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> 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