From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859AbaG1VWA (ORCPT ); Mon, 28 Jul 2014 17:22:00 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:41010 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751981AbaG1VVz (ORCPT ); Mon, 28 Jul 2014 17:21:55 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Kees Cook , Julien Tinnes , David Drysdale , Al Viro , Paolo Bonzini , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel\@vger.kernel.org" References: <1406296033-32693-1-git-send-email-drysdale@google.com> <1406296033-32693-12-git-send-email-drysdale@google.com> Date: Mon, 28 Jul 2014 14:18:04 -0700 In-Reply-To: (Andy Lutomirski's message of "Fri, 25 Jul 2014 10:18:05 -0700") Message-ID: <87vbqhp4hf.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1/c/DHs0QIMt1T8JG8HM6Eu8q8EzpaHZ0U= X-SA-Exim-Connect-IP: 98.234.51.111 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4920] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 0.5 XM_Body_Dirty_Words Contains a dirty word * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSSx_00 1+ SortaSexy Words + 1 Sexy Word * 1.0 XMSexyCombo_01 Sexy words in both body/subject X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *******;Andy Lutomirski X-Spam-Relay-Country: Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 13:58:17 -0700) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data Date: Mon, 28 Jul 2014 14:18:04 -0700 Message-ID: <87vbqhp4hf.fsf@x220.int.ebiederm.org> References: <1406296033-32693-1-git-send-email-drysdale@google.com> <1406296033-32693-12-git-send-email-drysdale@google.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Andy Lutomirski's message of "Fri, 25 Jul 2014 10:18:05 -0700") Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Kees Cook , Julien Tinnes , David Drysdale , Al Viro , Paolo Bonzini , LSM List , Greg Kroah-Hartman , Paul Moore , James Morris , Linux API , Meredydd Luff , Christoph Hellwig , "linux-kernel@vger.kernel.org" List-Id: linux-api@vger.kernel.org Andy Lutomirski 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