Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755194AbcDKXso (ORCPT ); Mon, 11 Apr 2016 19:48:44 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:37611 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754539AbcDKXsn (ORCPT ); Mon, 11 Apr 2016 19:48:43 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "H. Peter Anvin" Cc: Andy Lutomirski , Linus Torvalds , security@debian.org, "security\@kernel.org" , Al Viro , "security\@ubuntu.com \>\> security" , Peter Hurley , Serge Hallyn , Willy Tarreau , Aurelien Jarno , One Thousand Gnomes , Jann Horn , Greg KH , Linux Kernel Mailing List , Jiri Slaby , Florian Weimer References: <878u0s3orx.fsf_-_@x220.int.ebiederm.org> <1459819769-30387-1-git-send-email-ebiederm@xmission.com> <87twjcorwg.fsf@x220.int.ebiederm.org> <20160409140909.42315e6d@lxorguk.ukuu.org.uk> <83FE8CD2-C0A2-4ADB-AEBD-8DD89AD4F88A@zytor.com> <87bn5ij0x1.fsf@x220.int.ebiederm.org> <78205895-E11D-417F-91DC-4BCA0B61A122@zytor.com> Date: Mon, 11 Apr 2016 18:37:52 -0500 In-Reply-To: (H. Peter Anvin's message of "Mon, 11 Apr 2016 13:16:42 -0700") Message-ID: <877fg3emy7.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX189EYxQyWYz97tkOkUFBS1kjIv3Ex23gnY= X-SA-Exim-Connect-IP: 67.3.249.252 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;"H. Peter Anvin" X-Spam-Relay-Country: X-Spam-Timing: total 1614 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.4 (0.2%), b_tie_ro: 2.6 (0.2%), parse: 0.66 (0.0%), extract_message_metadata: 18 (1.1%), get_uri_detail_list: 1.39 (0.1%), tests_pri_-1000: 7 (0.4%), tests_pri_-950: 1.09 (0.1%), tests_pri_-900: 0.87 (0.1%), tests_pri_-400: 22 (1.4%), check_bayes: 21 (1.3%), b_tokenize: 6 (0.4%), b_tok_get_all: 8 (0.5%), b_comp_prob: 1.99 (0.1%), b_tok_touch_all: 3.0 (0.2%), b_finish: 0.62 (0.0%), tests_pri_0: 303 (18.8%), check_dkim_signature: 0.54 (0.0%), check_dkim_adsp: 113 (7.0%), tests_pri_500: 1255 (77.8%), poll_dns_idle: 1244 (77.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) 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 Content-Length: 1752 Lines: 46 "H. Peter Anvin" writes: > On April 11, 2016 1:12:22 PM PDT, Andy Lutomirski wrote: >>On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds >> wrote: >>> >>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski" >>wrote: >>>> >>>> >>>> What we *do* want to do, though, is to prevent the following: >>> >>> I don't see the point. Why do you bring up this insane scenario that >>nobody >>> can possibly care about? >>> >>> So you actually have any reason to believe somebody does that? >>> >>> I already asked about that earlier, and the silence was deafening. >> >>I have no idea, but I'm generally uncomfortable with magical things >>that bypass normal security policy. >> >>That being said, here's an idea for fixing this, at least in the long >>run. Add a new devpts mount option "no_ptmx_redirect" that turns off >>this behavior for the super in question. That is, opening /dev/ptmx >>if "pts/ptmx" points to something with no_ptmx_redirect set will fail. >>Distros shipping new kernels could be encouraged to (finally!) make >>/dev/ptmx a symlink and set this option. >> >>We just might be able to get away with spelling that option >>"newinstance". > > What about the idea of making the bind mount automatic? We could almost do that cleanly by playing with the /dev/ptmx dentry and implementing a d_automount method. That still needs the crazy path based lookup without permission checks. Unfortunately the filesystem not the device owns the dentry operations. My practical concern if we worked through the implementation details would be how would it interact with people who bind mount /dev/pts/ptmx on top of /dev/ptmx. We might get some strange new errors. Eric