[{"id":1759757,"web_url":"http://patchwork.ozlabs.org/comment/1759757/","msgid":"<20170829.160232.1901318933754673000.davem@davemloft.net>","list_archive_url":null,"date":"2017-08-29T23:02:32","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":15,"url":"http://patchwork.ozlabs.org/api/people/15/","name":"David Miller","email":"davem@davemloft.net"},"content":"From: Prakash Sangappa \nDate: Mon, 28 Aug 2017 17:12:20 -0700\n\n> Currently passing tid(gettid(2)) of a thread in struct ucred in\n> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise\n> it fails with EPERM error. Some applications deal with thread id\n> of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS\n> message. Basically, either tgid(pid of the process) or the tid of\n> the thread should be allowed without the need for CAP_SYS_ADMIN capability.\n> \n> SCM_CREDENTIALS will be used to determine the global id of a process or\n> a thread running inside a pid namespace.\n> \n> This patch adds necessary check to accept tid in SCM_CREDENTIALS\n> struct ucred.\n> \n> Signed-off-by: Prakash Sangappa \n\nI'm pretty sure that by the descriptions in previous changes to this\nfunction, what you are proposing is basically a minor form of PID\nspoofing which we only want someone with CAP_SYS_ADMIN over the\nPID namespace to be able to do.\n\nSorry, I'm not applying this.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhkgX3XvDz9s76\n\tfor ;\n\tWed, 30 Aug 2017 09:02:48 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751843AbdH2XCg (ORCPT );\n\tTue, 29 Aug 2017 19:02:36 -0400","from shards.monkeyblade.net ([184.105.139.130]:40988 \"EHLO\n\tshards.monkeyblade.net\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751275AbdH2XCf (ORCPT\n\t); Tue, 29 Aug 2017 19:02:35 -0400","from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net\n\t[74.93.104.98]) (using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(Client did not present a certificate)\n\t(Authenticated sender: davem-davemloft)\n\tby shards.monkeyblade.net (Postfix) with ESMTPSA id E430513D9B1F7;\n\tTue, 29 Aug 2017 16:02:34 -0700 (PDT)"],"Date":"Tue, 29 Aug 2017 16:02:32 -0700 (PDT)","Message-Id":"<20170829.160232.1901318933754673000.davem@davemloft.net>","To":"prakash.sangappa@oracle.com","Cc":"linux-kernel@vger.kernel.org, netdev@vger.kernel.org,\n\tebiederm@xmission.com, drepper@redhat.com","Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","From":"David Miller ","In-Reply-To":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>","X-Mailer":"Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)","Mime-Version":"1.0","Content-Type":"Text/Plain; charset=us-ascii","Content-Transfer-Encoding":"7bit","X-Greylist":"Sender succeeded SMTP AUTH, not delayed by\n\tmilter-greylist-4.5.12 (shards.monkeyblade.net\n\t[149.20.54.216]); Tue, 29 Aug 2017 16:02:35 -0700 (PDT)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759774,"web_url":"http://patchwork.ozlabs.org/comment/1759774/","msgid":"","list_archive_url":null,"date":"2017-08-29T23:59:18","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":72124,"url":"http://patchwork.ozlabs.org/api/people/72124/","name":"Prakash Sangappa","email":"prakash.sangappa@oracle.com"},"content":"On 08/29/2017 04:02 PM, David Miller wrote:\n> From: Prakash Sangappa \n> Date: Mon, 28 Aug 2017 17:12:20 -0700\n>\n>> Currently passing tid(gettid(2)) of a thread in struct ucred in\n>> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise\n>> it fails with EPERM error. Some applications deal with thread id\n>> of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS\n>> message. Basically, either tgid(pid of the process) or the tid of\n>> the thread should be allowed without the need for CAP_SYS_ADMIN capability.\n>>\n>> SCM_CREDENTIALS will be used to determine the global id of a process or\n>> a thread running inside a pid namespace.\n>>\n>> This patch adds necessary check to accept tid in SCM_CREDENTIALS\n>> struct ucred.\n>>\n>> Signed-off-by: Prakash Sangappa \n> I'm pretty sure that by the descriptions in previous changes to this\n> function, what you are proposing is basically a minor form of PID\n> spoofing which we only want someone with CAP_SYS_ADMIN over the\n> PID namespace to be able to do.\n\nThe fix is to allow passing tid of the calling thread itself not of any\nother thread or process. Curious why would this be considered\nas pid spoofing?\n\nThis change would enable a thread in a multi threaded process, running\ninside a pid namespace to be identified by the recipient of the\nmessage easily.\n\n\n>\n> Sorry, I'm not applying this.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhly72JTtz9sD9\n\tfor ;\n\tWed, 30 Aug 2017 10:00:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752001AbdH3AAT (ORCPT );\n\tTue, 29 Aug 2017 20:00:19 -0400","from userp1040.oracle.com ([156.151.31.81]:37054 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751786AbdH3AAS (ORCPT\n\t); Tue, 29 Aug 2017 20:00:18 -0400","from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2)\n\twith ESMTP id v7U00CeM005593\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 30 Aug 2017 00:00:12 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7U009V0031532\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Wed, 30 Aug 2017 00:00:09 GMT","from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv7U007Ip020021; Wed, 30 Aug 2017 00:00:08 GMT","from [10.132.173.156] (/10.132.173.156)\n\tby default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Tue, 29 Aug 2017 17:00:07 -0700"],"Reply-To":"prakash.sangappa@oracle.com","Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>\n\t<20170829.160232.1901318933754673000.davem@davemloft.net>","To":"David Miller ","Cc":"linux-kernel@vger.kernel.org, netdev@vger.kernel.org,\n\tebiederm@xmission.com, drepper@redhat.com","From":"\"prakash.sangappa\" ","Message-ID":"","Date":"Tue, 29 Aug 2017 16:59:18 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.5.1","MIME-Version":"1.0","In-Reply-To":"<20170829.160232.1901318933754673000.davem@davemloft.net>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit","X-Source-IP":"aserv0021.oracle.com [141.146.126.233]","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1759776,"web_url":"http://patchwork.ozlabs.org/comment/1759776/","msgid":"<87ziahzzhx.fsf@xmission.com>","list_archive_url":null,"date":"2017-08-30T00:10:50","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":196,"url":"http://patchwork.ozlabs.org/api/people/196/","name":"Eric W. Biederman","email":"ebiederm@xmission.com"},"content":"\"prakash.sangappa\" writes:\n\n> On 08/29/2017 04:02 PM, David Miller wrote:\n>> From: Prakash Sangappa \n>> Date: Mon, 28 Aug 2017 17:12:20 -0700\n>>\n>>> Currently passing tid(gettid(2)) of a thread in struct ucred in\n>>> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise\n>>> it fails with EPERM error. Some applications deal with thread id\n>>> of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS\n>>> message. Basically, either tgid(pid of the process) or the tid of\n>>> the thread should be allowed without the need for CAP_SYS_ADMIN capability.\n>>>\n>>> SCM_CREDENTIALS will be used to determine the global id of a process or\n>>> a thread running inside a pid namespace.\n>>>\n>>> This patch adds necessary check to accept tid in SCM_CREDENTIALS\n>>> struct ucred.\n>>>\n>>> Signed-off-by: Prakash Sangappa \n>> I'm pretty sure that by the descriptions in previous changes to this\n>> function, what you are proposing is basically a minor form of PID\n>> spoofing which we only want someone with CAP_SYS_ADMIN over the\n>> PID namespace to be able to do.\n>\n> The fix is to allow passing tid of the calling thread itself not of any\n> other thread or process. Curious why would this be considered\n> as pid spoofing?\n>\n> This change would enable a thread in a multi threaded process, running\n> inside a pid namespace to be identified by the recipient of the\n> message easily.\n\nI think a more practical problem is that change, changes what is being\npassed in the SCM_CREDENTIALS from a pid of a process to a tid of a\nthread. That could be confusing and that confusion could be exploited.\n\nIt is definitely confusing because in some instances a value can be both\na tgid and a tid.\n\nI definitely think this needs to be talked about in terms of changing\nwhat is passed in that field and what the consequences could be.\n\nI suspect you are ok. As nothing allows passing a tid today. But I\ndon't see any analysis on why passing a tid instead of a tgid will not\nconfuse the receiving application, and in such confusion introduce a\nsecurity hole.\n\nEric","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhmC770Mmz9sMN\n\tfor ;\n\tWed, 30 Aug 2017 10:11:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751773AbdH3ALP (ORCPT );\n\tTue, 29 Aug 2017 20:11:15 -0400","from out01.mta.xmission.com ([166.70.13.231]:39839 \"EHLO\n\tout01.mta.xmission.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751314AbdH3ALO (ORCPT\n\t); Tue, 29 Aug 2017 20:11:14 -0400","from in02.mta.xmission.com ([166.70.13.52])\n\tby out01.mta.xmission.com with esmtps\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dmqbB-0002qS-79; Tue, 29 Aug 2017 18:11:13 -0600","from 67-3-200-44.omah.qwest.net ([67.3.200.44]\n\thelo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dmqb5-0006Au-Gd; Tue, 29 Aug 2017 18:11:13 -0600"],"From":"ebiederm@xmission.com (Eric W. Biederman)","To":"\"prakash.sangappa\" ","Cc":"David Miller , linux-kernel@vger.kernel.org,\n\tnetdev@vger.kernel.org, drepper@redhat.com","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>\n\t<20170829.160232.1901318933754673000.davem@davemloft.net>\n\t","Date":"Tue, 29 Aug 2017 19:10:50 -0500","In-Reply-To":" (prakash\n\tsangappa's message of \"Tue, 29 Aug 2017 16:59:18 -0700\")","Message-ID":"<87ziahzzhx.fsf@xmission.com>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","X-XM-SPF":"eid=1dmqb5-0006Au-Gd; ; ; mid=<87ziahzzhx.fsf@xmission.com>; ; ;\n\thst=in02.mta.xmission.com; ; ; ip=67.3.200.44; ; ;\n\tfrm=ebiederm@xmission.com; ; ; spf=neutral","X-XM-AID":"U2FsdGVkX18aUwd3bb8xiI8+iiPv66F5ClAc3T0m/t0=","X-SA-Exim-Connect-IP":"67.3.200.44","X-SA-Exim-Mail-From":"ebiederm@xmission.com","X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on sa03.xmission.com","X-Spam-Level":"","X-Spam-Status":"No, score=-0.2 required=8.0 tests=ALL_TRUSTED,BAYES_20,\n\tDCC_CHECK_NEGATIVE, TVD_RCVD_IP, T_TM2_M_HEADER_IN_MSG,\n\tXMSolicitRefs_0, XMSubLong autolearn=disabled version=3.4.0","X-Spam-Report":"* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP\n\t* 0.7 XMSubLong Long Subject\n\t* 0.0 TVD_RCVD_IP Message was received from an IP address\n\t* 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.\n\t* -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20%\n\t* [score: 0.1497]\n\t* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC\n\t* [sa03 1397; Body=1 Fuz1=1 Fuz2=1]\n\t* 0.1 XMSolicitRefs_0 Weightloss drug","X-Spam-DCC":"XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 ","X-Spam-Combo":";\"prakash.sangappa\" ","X-Spam-Relay-Country":"","X-Spam-Timing":"total 5337 ms - load_scoreonly_sql: 0.21 (0.0%),\n\tsignal_user_changed: 5 (0.1%), b_tie_ro: 3.3 (0.1%),\n\tparse: 1.95 (0.0%), \n\textract_message_metadata: 30 (0.6%), get_uri_detail_list: 3.2 (0.1%), \n\ttests_pri_-1000: 10 (0.2%), tests_pri_-950: 2.5 (0.0%),\n\ttests_pri_-900: 2.0\n\t(0.0%), tests_pri_-400: 32 (0.6%), check_bayes: 30 (0.6%),\n\tb_tokenize: 12\n\t(0.2%), b_tok_get_all: 7 (0.1%), b_comp_prob: 4.6 (0.1%),\n\tb_tok_touch_all:\n\t2.3 (0.0%), b_finish: 0.90 (0.0%), tests_pri_0: 525 (9.8%),\n\tcheck_dkim_signature: 1.19 (0.0%), check_dkim_adsp: 7 (0.1%),\n\ttests_pri_500:\n\t4719 (88.4%), poll_dns_idle: 4702 (88.1%), rewrite_mail: 0.00 (0.0%)","Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","X-Spam-Flag":"No","X-SA-Exim-Version":"4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)","X-SA-Exim-Scanned":"Yes (on in02.mta.xmission.com)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1760372,"web_url":"http://patchwork.ozlabs.org/comment/1760372/","msgid":"<87inh5ymv2.fsf@xmission.com>","list_archive_url":null,"date":"2017-08-30T17:41:21","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":196,"url":"http://patchwork.ozlabs.org/api/people/196/","name":"Eric W. Biederman","email":"ebiederm@xmission.com"},"content":"Prakash Sangappa writes:\n\n> On 8/29/17 5:10 PM, ebiederm@xmission.com wrote:\n>\n> \"prakash.sangappa\" writes:\n>\n> On 08/29/2017 04:02 PM, David Miller wrote:\n>\n> From: Prakash Sangappa \n> Date: Mon, 28 Aug 2017 17:12:20 -0700\n>\n> Currently passing tid(gettid(2)) of a thread in struct ucred in\n> SCM_CREDENTIALS message requires CAP_SYS_ADMIN capability otherwise\n> it fails with EPERM error. Some applications deal with thread id\n> of a thread(tid) and so it would help to allow tid in SCM_CREDENTIALS\n> message. Basically, either tgid(pid of the process) or the tid of\n> the thread should be allowed without the need for CAP_SYS_ADMIN capability.\n>\n> SCM_CREDENTIALS will be used to determine the global id of a process or\n> a thread running inside a pid namespace.\n>\n> This patch adds necessary check to accept tid in SCM_CREDENTIALS\n> struct ucred.\n>\n> Signed-off-by: Prakash Sangappa \n>\n> I'm pretty sure that by the descriptions in previous changes to this\n> function, what you are proposing is basically a minor form of PID\n> spoofing which we only want someone with CAP_SYS_ADMIN over the\n> PID namespace to be able to do.\n>\n> The fix is to allow passing tid of the calling thread itself not of any\n> other thread or process. Curious why would this be considered\n> as pid spoofing?\n>\n> This change would enable a thread in a multi threaded process, running\n> inside a pid namespace to be identified by the recipient of the\n> message easily.\n>\n> I think a more practical problem is that change, changes what is being\n> passed in the SCM_CREDENTIALS from a pid of a process to a tid of a\n> thread. That could be confusing and that confusion could be exploited.\n>\n> It will be upto the application to decide what to pass, either pid of the \n> process or tid of the thread and the co-operating process receiving the\n> message would know what to expect. It does not change or make it \n> mandatory to pass tid. \n>\n> \n> It is definitely confusing because in some instances a value can be both\n> a tgid and a tid.\n>\n> \n> I definitely think this needs to be talked about in terms of changing\n> what is passed in that field and what the consequences could be.\n>\n> Agreed that If the receiving process expects a pid and the process sending\n> the message sends tid, it can cause confusion, but why would that occur? \n> Shouldn't the sending process know what is the receiving process expecting?\n>\n> \n> I suspect you are ok. As nothing allows passing a tid today. But I\n> don't see any analysis on why passing a tid instead of a tgid will not\n> confuse the receiving application, and in such confusion introduce a\n> security hole.\n>\n> It would seem that there has to be an understanding between the two\n> processes what is being passed(pid or tid) when communicating with \n> each other.\n\nWhich is the issue. SCM_CREDENTIALS is fundamentally about dealing with\nprocesses that are in a less than completely trusting relationship.\n\n> With regards to security, the question basically is what is the consequence\n> of passing the wrong id. As I understand it, Interpreting the id to be pid \n> or tid, the effective uid and gid will be the same. It would be a problem \n> only if the incorrect interpretation of the id would refer a different process. \n> But that cannot happen as the the global tid(gettid() of a thread is\n> unique.\n\nThere is also the issue that the receiving process could look, not see\nthe pid in proc and assume the sending process is dead. That I suspect\nis the larger danger.\n\n> As long as the thread is alive, that id cannot reference another process / thread. \n> Unless the thread were to exit and the id gets recycled and got used for another \n> thread or process. This would be no different from a process exiting and its\n> pid getting recycled which is the case now.\n\nLargely I agree.\n\nIf all you want are pid translations I suspect the are far easier ways\nthant updating the SCM_CREDENTIALS code.\n\nEric","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjCVz5jSmz9sN5\n\tfor ;\n\tThu, 31 Aug 2017 03:42:03 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751388AbdH3Rlu (ORCPT );\n\tWed, 30 Aug 2017 13:41:50 -0400","from out03.mta.xmission.com ([166.70.13.233]:39851 \"EHLO\n\tout03.mta.xmission.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750995AbdH3Rls (ORCPT\n\t); Wed, 30 Aug 2017 13:41:48 -0400","from in01.mta.xmission.com ([166.70.13.51])\n\tby out03.mta.xmission.com with esmtps\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dn6zq-0002IT-4i; Wed, 30 Aug 2017 11:41:46 -0600","from 67-3-200-44.omah.qwest.net ([67.3.200.44]\n\thelo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dn6zj-0007zk-FP; Wed, 30 Aug 2017 11:41:45 -0600"],"From":"ebiederm@xmission.com (Eric W. Biederman)","To":"Prakash Sangappa ","Cc":"David Miller , linux-kernel@vger.kernel.org,\n\tnetdev@vger.kernel.org, drepper@redhat.com","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>\n\t<20170829.160232.1901318933754673000.davem@davemloft.net>\n\t\n\t<87ziahzzhx.fsf@xmission.com>\n\t","Date":"Wed, 30 Aug 2017 12:41:21 -0500","In-Reply-To":" (Prakash\n\tSangappa's message of \"Wed, 30 Aug 2017 08:57:08 -0700\")","Message-ID":"<87inh5ymv2.fsf@xmission.com>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","X-XM-SPF":"eid=1dn6zj-0007zk-FP; ; ; mid=<87inh5ymv2.fsf@xmission.com>; ; ;\n\thst=in01.mta.xmission.com; ; ; ip=67.3.200.44; ; ;\n\tfrm=ebiederm@xmission.com; ; ; spf=neutral","X-XM-AID":"U2FsdGVkX1+TlkZNyn+6WIrA1z+nGDsM0hGn6o66mUI=","X-SA-Exim-Connect-IP":"67.3.200.44","X-SA-Exim-Mail-From":"ebiederm@xmission.com","X-Spam-Checker-Version":"SpamAssassin 3.4.1 (2015-04-28) on sa06.xmission.com","X-Spam-Level":"","X-Spam-Status":"No, score=0.6 required=8.0 tests=ALL_TRUSTED,BAYES_50,\n\tDCC_CHECK_NEGATIVE, TVD_RCVD_IP, T_TM2_M_HEADER_IN_MSG,\n\tXMSolicitRefs_0, XMSubLong autolearn=disabled version=3.4.1","X-Spam-Report":"* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP\n\t* 0.7 XMSubLong Long Subject\n\t* 0.0 TVD_RCVD_IP Message was received from an IP address\n\t* 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.\n\t* 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%\n\t* [score: 0.4839]\n\t* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC\n\t* [sa06 1397; Body=1 Fuz1=1 Fuz2=1]\n\t* 0.1 XMSolicitRefs_0 Weightloss drug","X-Spam-DCC":"XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 ","X-Spam-Combo":";Prakash Sangappa ","X-Spam-Relay-Country":"","X-Spam-Timing":"total 5682 ms - load_scoreonly_sql: 0.03 (0.0%),\n\tsignal_user_changed: 2.5 (0.0%), b_tie_ro: 1.73 (0.0%),\n\tparse: 0.83 (0.0%), \n\textract_message_metadata: 15 (0.3%), get_uri_detail_list: 2.6 (0.0%), \n\ttests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.18 (0.0%),\n\ttests_pri_-900: 0.97\n\t(0.0%), tests_pri_-400: 28 (0.5%), check_bayes: 27 (0.5%),\n\tb_tokenize: 8\n\t(0.1%), b_tok_get_all: 10 (0.2%), b_comp_prob: 3.1 (0.1%),\n\tb_tok_touch_all:\n\t3.0 (0.1%), b_finish: 0.61 (0.0%), tests_pri_0: 338 (5.9%),\n\tcheck_dkim_signature: 0.51 (0.0%), check_dkim_adsp: 2.5 (0.0%),\n\ttests_pri_500: 5285 (93.0%), poll_dns_idle: 5279 (92.9%),\n\trewrite_mail: 0.00 (0.0%)","Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","X-Spam-Flag":"No","X-SA-Exim-Version":"4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)","X-SA-Exim-Scanned":"Yes (on in01.mta.xmission.com)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761862,"web_url":"http://patchwork.ozlabs.org/comment/1761862/","msgid":"","list_archive_url":null,"date":"2017-09-01T17:30:31","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":72124,"url":"http://patchwork.ozlabs.org/api/people/72124/","name":"Prakash Sangappa","email":"prakash.sangappa@oracle.com"},"content":"On 8/30/17 10:41 AM, ebiederm@xmission.com wrote:\n> Prakash Sangappa writes:\n>\n>\n>> With regards to security, the question basically is what is the consequence\n>> of passing the wrong id. As I understand it, Interpreting the id to be pid\n>> or tid, the effective uid and gid will be the same. It would be a problem\n>> only if the incorrect interpretation of the id would refer a different process.\n>> But that cannot happen as the the global tid(gettid() of a thread is\n>> unique.\n> There is also the issue that the receiving process could look, not see\n> the pid in proc and assume the sending process is dead. That I suspect\n> is the larger danger.\n>\n\nWill this not be a bug in the application, if it is sending the wrong id?\n\n>> As long as the thread is alive, that id cannot reference another process / thread.\n>> Unless the thread were to exit and the id gets recycled and got used for another\n>> thread or process. This would be no different from a process exiting and its\n>> pid getting recycled which is the case now.\n> Largely I agree.\n>\n> If all you want are pid translations I suspect the are far easier ways\n> thant updating the SCM_CREDENTIALS code.\n\nWhat would be an another easier & efficient way of doing pid translation?\n\nShould a new API/mechanism be considered mainly for pid translation purpose\nfor use with pid namespaces, say based on 'pipe' something similar to \nI_SENDFD?\n\nThanks,\n-Prakash.\n\n> Eric\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkR9730XVz9t32\n\tfor ;\n\tSat, 2 Sep 2017 03:30:51 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752388AbdIARaj (ORCPT );\n\tFri, 1 Sep 2017 13:30:39 -0400","from userp1040.oracle.com ([156.151.31.81]:40789 \"EHLO\n\tuserp1040.oracle.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752338AbdIARah (ORCPT\n\t); Fri, 1 Sep 2017 13:30:37 -0400","from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])\n\tby userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with\n\tESMTP id v81HUWjE022004\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 1 Sep 2017 17:30:32 GMT","from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])\n\tby userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v81HUWUQ013507\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256\n\tverify=OK); Fri, 1 Sep 2017 17:30:32 GMT","from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])\n\tby userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id\n\tv81HUWbF028152; Fri, 1 Sep 2017 17:30:32 GMT","from dhcp-whq-twvpn-1-vpnpool-10-159-147-71.vpn.oracle.com\n\t(/10.159.147.71) by default (Oracle Beehive Gateway v4.0)\n\twith ESMTP ; Fri, 01 Sep 2017 10:30:31 -0700"],"Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","To":"\"Eric W. Biederman\" ","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>\n\t<20170829.160232.1901318933754673000.davem@davemloft.net>\n\t\n\t<87ziahzzhx.fsf@xmission.com>\n\t\n\t<87inh5ymv2.fsf@xmission.com>","Cc":"David Miller , linux-kernel@vger.kernel.org,\n\tnetdev@vger.kernel.org, drepper@redhat.com","From":"Prakash Sangappa ","Message-ID":"","Date":"Fri, 1 Sep 2017 10:30:31 -0700","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)\n\tGecko/20100101 Thunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<87inh5ymv2.fsf@xmission.com>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit","X-Source-IP":"userv0021.oracle.com [156.151.31.71]","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1761942,"web_url":"http://patchwork.ozlabs.org/comment/1761942/","msgid":"<878thyw73u.fsf@xmission.com>","list_archive_url":null,"date":"2017-09-01T19:29:09","subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","submitter":{"id":196,"url":"http://patchwork.ozlabs.org/api/people/196/","name":"Eric W. Biederman","email":"ebiederm@xmission.com"},"content":"Prakash Sangappa writes:\n\n> On 8/30/17 10:41 AM, ebiederm@xmission.com wrote:\n>> Prakash Sangappa writes:\n>>\n>>\n>>> With regards to security, the question basically is what is the consequence\n>>> of passing the wrong id. As I understand it, Interpreting the id to be pid\n>>> or tid, the effective uid and gid will be the same. It would be a problem\n>>> only if the incorrect interpretation of the id would refer a different process.\n>>> But that cannot happen as the the global tid(gettid() of a thread is\n>>> unique.\n>> There is also the issue that the receiving process could look, not see\n>> the pid in proc and assume the sending process is dead. That I suspect\n>> is the larger danger.\n>>\n>\n> Will this not be a bug in the application, if it is sending the wrong\n> id?\n\nNo. It could be deliberate and malicious.\n\n>>> As long as the thread is alive, that id cannot reference another process / thread.\n>>> Unless the thread were to exit and the id gets recycled and got used for another\n>>> thread or process. This would be no different from a process exiting and its\n>>> pid getting recycled which is the case now.\n>> Largely I agree.\n>>\n>> If all you want are pid translations I suspect the are far easier ways\n>> thant updating the SCM_CREDENTIALS code.\n>\n> What would be an another easier & efficient way of doing pid translation?\n>\n> Should a new API/mechanism be considered mainly for pid translation purpose\n> for use with pid namespaces, say based on 'pipe' something similar to\n> I_SENDFD?\n\nThere are proc files that provide all of the pids of a process you can\nread those.\n\nOther possibilities exist if you want to go that fast.\n\nEric","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkTp61dhQz9sPt\n\tfor ;\n\tSat, 2 Sep 2017 05:29:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752363AbdIAT3Z (ORCPT );\n\tFri, 1 Sep 2017 15:29:25 -0400","from out01.mta.xmission.com ([166.70.13.231]:54823 \"EHLO\n\tout01.mta.xmission.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752281AbdIAT3W (ORCPT\n\t); Fri, 1 Sep 2017 15:29:22 -0400","from in02.mta.xmission.com ([166.70.13.52])\n\tby out01.mta.xmission.com with esmtps\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dnrd2-0003R6-9m; Fri, 01 Sep 2017 13:29:20 -0600","from 67-3-200-44.omah.qwest.net ([67.3.200.44]\n\thelo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa\n\t(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1dnrcw-0003yX-Ap; Fri, 01 Sep 2017 13:29:20 -0600"],"From":"ebiederm@xmission.com (Eric W. Biederman)","To":"Prakash Sangappa ","Cc":"David Miller , linux-kernel@vger.kernel.org,\n\tnetdev@vger.kernel.org, drepper@redhat.com","References":"<1503965540-30393-1-git-send-email-prakash.sangappa@oracle.com>\n\t<20170829.160232.1901318933754673000.davem@davemloft.net>\n\t\n\t<87ziahzzhx.fsf@xmission.com>\n\t\n\t<87inh5ymv2.fsf@xmission.com>\n\t","Date":"Fri, 01 Sep 2017 14:29:09 -0500","In-Reply-To":" (Prakash\n\tSangappa's message of \"Fri, 1 Sep 2017 10:30:31 -0700\")","Message-ID":"<878thyw73u.fsf@xmission.com>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","X-XM-SPF":"eid=1dnrcw-0003yX-Ap; ; ; mid=<878thyw73u.fsf@xmission.com>; ; ;\n\thst=in02.mta.xmission.com; ; ; ip=67.3.200.44; ; ;\n\tfrm=ebiederm@xmission.com; ; ; spf=neutral","X-XM-AID":"U2FsdGVkX19FsWDGYGQbueqWl4coTlepa5d3tOTf154=","X-SA-Exim-Connect-IP":"67.3.200.44","X-SA-Exim-Mail-From":"ebiederm@xmission.com","X-Spam-Checker-Version":"SpamAssassin 3.4.1 (2015-04-28) on sa05.xmission.com","X-Spam-Level":"","X-Spam-Status":"No, score=-0.8 required=8.0 tests=ALL_TRUSTED,BAYES_05,\n\tDCC_CHECK_NEGATIVE,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG,XMSubLong\n\tautolearn=disabled version=3.4.1","X-Spam-Report":"* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP\n\t* 0.0 TVD_RCVD_IP Message was received from an IP address\n\t* 0.7 XMSubLong Long Subject\n\t* 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available.\n\t* -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%\n\t* [score: 0.0175]\n\t* -0.0 DCC_CHECK_NEGATIVE Not listed in DCC\n\t* [sa05 1397; Body=1 Fuz1=1 Fuz2=1]","X-Spam-DCC":"XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 ","X-Spam-Combo":";Prakash Sangappa ","X-Spam-Relay-Country":"","X-Spam-Timing":"total 5683 ms - load_scoreonly_sql: 0.05 (0.0%),\n\tsignal_user_changed: 2.6 (0.0%), b_tie_ro: 1.77 (0.0%),\n\tparse: 0.91 (0.0%), \n\textract_message_metadata: 14 (0.2%), get_uri_detail_list: 1.46 (0.0%),\n\ttests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.14 (0.0%),\n\ttests_pri_-900: 0.89\n\t(0.0%), tests_pri_-400: 20 (0.4%), check_bayes: 19 (0.3%),\n\tb_tokenize: 6\n\t(0.1%), b_tok_get_all: 7 (0.1%), b_comp_prob: 1.88 (0.0%),\n\tb_tok_touch_all:\n\t2.3 (0.0%), b_finish: 0.55 (0.0%), tests_pri_0: 233 (4.1%),\n\tcheck_dkim_signature: 0.51 (0.0%), check_dkim_adsp: 2.8 (0.1%),\n\ttests_pri_500: 5401 (95.0%), poll_dns_idle: 5393 (94.9%),\n\trewrite_mail: 0.00 (0.0%)","Subject":"Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS\n\twithout CAP_SYS_ADMIN","X-Spam-Flag":"No","X-SA-Exim-Version":"4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)","X-SA-Exim-Scanned":"Yes (on in02.mta.xmission.com)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]