Messages in this thread |  | | From | (Eric W. Biederman) | Date | Wed, 16 Aug 2017 11:43:39 -0500 | Subject | Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation |
| |
"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
|  |