From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751488AbcDOUyl (ORCPT ); Fri, 15 Apr 2016 16:54:41 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:33347 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbcDOUyj (ORCPT ); Fri, 15 Apr 2016 16:54:39 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Linus Torvalds , "H. Peter Anvin" , 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> <570D4781.3070600@zytor.com> <877ffyzy1j.fsf_-_@x220.int.ebiederm.org> Date: Fri, 15 Apr 2016 15:43:56 -0500 In-Reply-To: (Andy Lutomirski's message of "Fri, 15 Apr 2016 09:49:21 -0700") Message-ID: <87y48evbzn.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: U2FsdGVkX1+QsFV2dkcLYeTlX0EyHW0jZ3hbtLWqb1M= 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 * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 TVD_RCVD_IP Message was received from an IP address * 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 * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 969 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 4.5 (0.5%), b_tie_ro: 3.3 (0.3%), parse: 3.5 (0.4%), extract_message_metadata: 38 (3.9%), get_uri_detail_list: 6 (0.6%), tests_pri_-1000: 17 (1.7%), tests_pri_-950: 2.6 (0.3%), tests_pri_-900: 2.1 (0.2%), tests_pri_-400: 55 (5.7%), check_bayes: 53 (5.4%), b_tokenize: 21 (2.2%), b_tok_get_all: 16 (1.6%), b_comp_prob: 7 (0.7%), b_tok_touch_all: 3.3 (0.3%), b_finish: 1.00 (0.1%), tests_pri_0: 823 (84.9%), check_dkim_signature: 1.23 (0.1%), check_dkim_adsp: 6 (0.6%), tests_pri_500: 11 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 01/16] devpts: Attempting to get it right 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 Andy Lutomirski writes: > On Fri, Apr 15, 2016 at 8:34 AM, Eric W. Biederman > wrote: >> >> To recap the situation for those who have not been following closely. >> >> There are programs such as xen-create-image that run as root and setup >> a chroot environment with: >> "mknod dev/ptmx c 5 2" >> "mkdir dev/pts" >> "mount -t devpts none dev/pts" >> >> Which mostly works but stomps the mount options of the system /dev/pts. >> In particular the options of "gid=5,mode=620" are lost resulting in a >> situation where creating a new pty by opening /dev/ptmx results in >> that pty having the wrong permissions. >> >> Some distributions have been working around this problem by continuing >> to install a setuid root pt_chown binary that will be called by glibc >> to fix the permissions. >> >> Maintaining a setuid root pt_chown binary is not too scary until >> multiple instances of devpts are considered at which point it becomes >> possible to trick the setuid root pt_chown binary into operating on the >> wrong files and directories. Leading to all of the things one might >> fear when a setuid root binary goes wrong. >> >> The following patchset digs us out of that hole by carefully devpts and >> /dev/ptmx in a way that does not introduce any userspace regressions, >> while making each mount of devpts distinct (so pt_chown is unnecessary) >> and arranging things so that enough information is available so >> that a secure pt_chown binary is possible to write if that is ever >> needed. >> >> The approach I have chosen to take is to first enhance the /dev/ptmx >> device node to automount /dev/pts/ptmx on top of it. This leads to a >> simple high performance solution that allows applications such as >> xen-create-image (that call "mknod ptmx c 5 2" and mount devpts) >> to continue to run as before even when they are given a non-system >> instance of devpts. >> >> Using automountic bind mounts of /dev/pts/ptmx results in no new >> security cases to consider as this can already be done, and actually >> results in a simplification of the analysis of the code. As now all >> opens of ptmx are of /dev/pts/ptmx. /dev/ptmx is now just a magic >> mountpoint that does the right thing. > > And what happens when someone tries to rm /dev/ptmx or unmount their > pts instance or similar? Unlink works (that was a trivial extension of the existing semantics). It really didn't make sense that we honor mounts that can appear and disappear on their own as much as we honor other mounts. > What happens if /dev/ptmx is in a mount that > is set to propagate elsewhere but /dev/pts was replaced by an > unprivileged user? (Can this happen? I'm not sure.) Well nothing that currently works will break in such a weird scenario. So I call what happens in the crazy cases you are imagining well defined obvious semantics (aka all you need to do is to apply the current rules). Plus you have to be pretty crazy to do something like that. Further I am 90% certain that the propogation semantics on the /dev directory are what define how mounts of /dev/pts and /dev/ptmx propagate. > This seems much weirder than the previous approach. I think I'm > starting to come over to Linus' view -- the magic lookup was fine, and > I still can't think of a case where the permissions matter. If we > care, we can cause the /dev/ptmx magic lookup to fail if the devpts it > finds was created with newinstance. (After all, devpts instances > created with newinstance *never* worked via /dev/ptmx magic.) It isn't weirder. The rules are actually just a little simpler. That is my take away from playing with it and working with it. The code is actually really boring and just works in practice. But please take my branch and play with it, and see if you can get it to do something weird and magical. It is observable enough I don't expect you can. But please. If I am wrong I will happily scrap this. Right now this looks from my vanrage point like really really obvious semantics, that don't cause regressions, and that are easy to understand and observe. Eric