"Michael Kerrisk (man-pages)" [off-list ref] writes:

On 06/09/2017 07:01 PM, Aleksa Sarai wrote:

quoted

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.

quoted

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: <redacted>
Signed-off-by: Aleksa Sarai <redacted>

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers