Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759037AbcDHV5G (ORCPT ); Fri, 8 Apr 2016 17:57:06 -0400 Received: from mail-ob0-f178.google.com ([209.85.214.178]:36441 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753917AbcDHV5E (ORCPT ); Fri, 8 Apr 2016 17:57:04 -0400 MIME-Version: 1.0 In-Reply-To: <87d1pzn60f.fsf@x220.int.ebiederm.org> References: <878u0s3orx.fsf_-_@x220.int.ebiederm.org> <1459819769-30387-1-git-send-email-ebiederm@xmission.com> <87twjcorwg.fsf@x220.int.ebiederm.org> <87d1pzn60f.fsf@x220.int.ebiederm.org> From: Andy Lutomirski Date: Fri, 8 Apr 2016 14:56:43 -0700 Message-ID: Subject: Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup To: "Eric W. Biederman" Cc: Linus Torvalds , security@debian.org, "security@kernel.org" , Al Viro , "security@ubuntu.com >> security" , Peter Hurley , Serge Hallyn , Willy Tarreau , Aurelien Jarno , Jann Horn , Greg KH , Linux Kernel Mailing List , Jiri Slaby , Florian Weimer , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1713 Lines: 42 On Fri, Apr 8, 2016 at 2:29 PM, Eric W. Biederman wrote: > Andy Lutomirski writes: > >> On Apr 8, 2016 12:05 PM, "Linus Torvalds" wrote: >>> >>> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman >>> wrote: >>> > >>> > Given that concern under the rule we don't break userspace we have to >>> > check the permissions of /dev/pts/ptmx when we are creating a new pty, >>> > on a instance of devpts that was created with newinstance. >>> >>> The rule is that we don't break existing installations. >>> >>> If somebody has root and installs a "ptmx" node in an existing mount >>> space next to a pts subdirectory, that's not a security issue, nor is >>> it going to break any existing installation. >> >> What Eric's saying is that you don't have to be root for this. >> >> But Eric, I think there might be a better mitigation. For a ptmx >> chardev, just fail the open if the chardev's vfsmount or the devpts's >> vfsmount doesn't belong to the same userns as the devpts's superblock. >> After all, setting this attack up requires the caps on one of the >> vfsmounts, and if you have those caps you could attack your own devpts >> instance quite easily. Would that work? > > I don't think so. For one it depends on getting s_user_ns which should > happen but is not there yet. For another the way you describe > it you would break the case of > > unshare(CLONE_NEWUSER); > unshare(CLONE_NEWNS); > open("/dev/ptmx"); > > Which is actually more likely to break userspace than anything else we > have considered. I know people actually do that. > Hmm, you're right. Never mind. --Andy