On Mon, Jan 16, 2017 at 9:15 AM, Djalal Harouni <tixxdz@xxxxxxxxx> wrote: > Cc linux-api > > On Mon, Jan 16, 2017 at 2:23 PM, Djalal Harouni <tixxdz@xxxxxxxxx> wrote: >> >> From: Djalal Harouni <tixxdz@xxxxxxxxx> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
