linux-kernel - Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Aug 2017 14:43:29 +1000
From:   Aleksa Sarai <asarai@...e.de>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     linux-man@...r.kernel.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Valentin Rothberg <vrothberg@...e.com>,
        Jiri Slaby <jslaby@...e.com>,
        containers@...ts.linux-foundation.org
Subject: Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

> 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.

Yup, that sounds good.

> 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.

There are a few posix_-style functions provided by glibc that are just 
wrappers around the open+ptsname combo that I mention earlier in the 
sentence (and thus are vulnerable to the same issue). But if you feel 
it's confusing you can feel free to drop it.

Thanks.

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/