Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data

On Mon, Jul 28, 2014 at 2:18 PM, Eric W. Biederman
[off-list ref] wrote:

Andy Lutomirski [off-list ref] writes:

quoted

[cc: Eric Biederman]

quoted

Can we do one better and add a flag to prevent any non-self pid
lookups?  This might actually be easy on top of the pid namespace work
(e.g. we could change the way that find_task_by_vpid works).

It's far from just being signals.  There's access_process_vm, ptrace,
all the signal functions, clock_gettime (see CPUCLOCK_PID -- yes, this
is ridiculous), and probably some others that I've forgotten about or
never noticed in the first place.

So here is the practical question.

Are these processes that only can send signals to their thread group
allowed to call fork()?


If fork is allowed and all pid lookups are restricted to their own
thread group that wait, waitpid, and all of the rest of the wait family
will never return the pids of their children, and zombies will
accumulate.  Aka the semantics are fundamentally broken.

Good point.

I can imagine at least three ways that fork() could continue working, though:

1. Allow lookups of immediate children, too.  (I don't love this one.)
2. Allow non-self pids to be translated in but not out.  This way
P_ALL will continue working.
3. Have the kernel treat any PID-restricted process as though it were NOCLDWAIT.

I think I like #3.  Thoughts?

If fork is not allowed pid namespaces already solve this problem.

PID namespaces are fairly heavyweight.  Julien pointed out that using
PID namespaces requires a bunch of dummy PID 1 processes.

--Andy