From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: Aleksa Sarai <asarai@suse.de>, linux-man@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
        Jiri Slaby <jslaby@suse.com>,
        Christian Brauner <christian.brauner@ubuntu.com>
References: <20170609170147.32311-1-asarai@suse.de>
        <11706e49-8271-ed8c-3747-19b3e8f2850d@gmail.com>
Date: Wed, 16 Aug 2017 11:43:39 -0500
In-Reply-To: <11706e49-8271-ed8c-3747-19b3e8f2850d@gmail.com> (Michael
        Kerrisk's message of "Tue, 15 Aug 2017 21:27:33 +0200")
Message-ID: <878tijwjic.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Subject: Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3102
Lines: 66

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> On 06/09/2017 07:01 PM, Aleksa Sarai wrote:
>> The feature this patch references has currently only been accepted into
>> tty-testing, but Greg told me to kick this down to man-pages. As a
>> result, I can't reference upstream commit id's because the code isn't in
>> Linus' tree yet -- should I resend this once it lands in tty-next or
>> Linus' tree?
>> 
>> Also obviously the release version is a bit of a lie.
>
> Hello Aleksa,
>
> I've applied this patch, and then tweaked the wording a little. Could
> you please check the following text:
>
>        TIOCGPTPEER    int flags
>               (since Linux 4.13) Given  a  file  descriptor  in  fd  that
>               refers  to  a  pseudoterminal  master, open (with the given
>               open(2)-style flags) and return a new file descriptor  that
>               refers to the peer pseudoterminal slave device.  This oper‐
>               ation can be performed regardless of whether  the  pathname
>               of  the  slave  device  is  accessible  through the calling
>               process's mount namespaces.
>
>               Security-conscious programs interacting with namespaces may
>               wish  to  use  this  operation rather than open(2) with the
>               pathname returned by ptsname(3), and similar library  func‐
>               tions that have insecure APIs.
>
> I also have a question on the last sentence: what are the "similar library
> functions that have insecure APIs"? It's not clear to me what you are 
> referring to here.

A couple of things to note on the bigger picture.

The glibc library on all distributions has been changed to not have a
setuid binary pt_chown, that uses ptsname.  This was the primary fix
for the security issue.

The behavior of opening /dev/ptmx has been changed to perform a path
lookup relative to the location of /dev/ptmx of  ./pts/ptmx and open
it it is a devpts filesystem and to fail otherwise.    This further
makes it hard to confuse userspace this way as /dev/ptmx always
corresponds to /dev/pts/ptmx.  Even in chroots and in other mount
namespaces.

Both of these changes largely makes glibc's use of these features
secure.  /dev/ptmx always corresponds to /dev/pts and there no readily
available suid root applications too fool.

That makes TIOCGPTPEER a very nice addition, but not something people
have to scramble to use to ensure their system is secure.  As a hostile
environment now has to work very hard to confuse the existing mechanisms.

>> This is an ioctl(2) recently added by myself, to allow for container
>> runtimes and other programs that interact with (potentially hostile)
>> Linux namespaces to safely create {master,slave} pseudoterminal pairs
>> without needing to open potentially unsafe /dev/pts/... filenames that
>> may be malicious mountpoints or similar in an untrusted namespace
>> (avoiding the endless issues with ptsname(3) and similar approaches).
>> 
>> Cc: <containers@lists.linux-foundation.org>
>> Signed-off-by: Aleksa Sarai <asarai@suse.de>

Eric