[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVUHn=KWyjzCa15VffZej3+ge7Js=nN_ymJpoOuWJ=FRg@mail.gmail.com>
Date: Fri, 8 Apr 2016 13:43:16 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: security@...ian.org, "security@...nel.org" <security@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
"security@...ntu.com >> security" <security@...ntu.com>,
Peter Hurley <peter@...leysoftware.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Serge Hallyn <serge.hallyn@...ntu.com>,
Willy Tarreau <w@....eu>,
Aurelien Jarno <aurelien@...el32.net>,
Jann Horn <jann@...jh.net>, Greg KH <greg@...ah.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jiri Slaby <jslaby@...e.com>,
Florian Weimer <fw@...eb.enyo.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated
devpts via path lookup
On Apr 8, 2016 12:05 PM, "Linus Torvalds" <torvalds@...ux-foundation.org> wrote:
>
> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
> <ebiederm@...ssion.com> 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?
>
> The whole point of the patch is that yes, we change semantics. A
> change of semantics means that people will see situations where the
> behavior is different. But that's not "breaking user space", that's
> just "ok, you can see a difference".
>
> Linus
Powered by blists - more mailing lists