[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87vbqhp4hf.fsf@x220.int.ebiederm.org>
Date: Mon, 28 Jul 2014 14:18:04 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andy Lutomirski <luto@...capital.net>
Cc: Kees Cook <keescook@...omium.org>, Julien Tinnes <jln@...gle.com>,
David Drysdale <drysdale@...gle.com>,
Al Viro <viro@...iv.linux.org.uk>,
Paolo Bonzini <pbonzini@...hat.com>,
LSM List <linux-security-module@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Paul Moore <paul@...l-moore.com>,
James Morris <james.l.morris@...cle.com>,
Linux API <linux-api@...r.kernel.org>,
Meredydd Luff <meredydd@...atehouse.org>,
Christoph Hellwig <hch@...radead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data
Andy Lutomirski <luto@...capital.net> writes:
> [cc: Eric Biederman]
>
> 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.
If fork is not allowed pid namespaces already solve this problem.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists