"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx>
>> Signed-off-by: Aleksa Sarai <asarai@xxxxxxx>
Eric
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
