Re: Hard-coding PTY device node numbers in userspace

* Greg KH:

On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:

quoted

We want to reject PTY devices from other namespaces as valid input to
the ttyname and ttyname_r functions, while still providing a hint to
callers that the device is, in fact, a PTY.  Christian Brauner wrote a
glibc patch for this:

  <https://sourceware.org/ml/libc-alpha/2017-01/msg00531.html>

It hard-codes the major PTY device number range.  Is this feasible?
Is it part of the stable userspace ABI for the TTY subsystem?

What major numbers are you using in the patch '2' and '3'?

I think there is just one patch, and the check looks like this:

  static inline int
  is_pty (struct stat64 *sb)
  {
    int m = major (sb->st_rdev);
    return (136 <= m && m <= 143);
  }

And yes,
major numbers are static and you should be fine to rely on them.  But
can't you test that the device is a pty to verify it?

It's not entirely clear what exactly a PTY descriptor should be for
ttyname.  Going forward, we only want to treat descriptors for PTY
devices which can be accessed using /dev/pts paths in the current
namespace as PTYs.  Christian's patch adds a separate error code for
the case where the descriptor is a PTY, but it comes from a different
namespace.

I'm concerned that some software out there assumes that if standard
input is a PTY according to ttyname, it is safe to chown it.  There
have been security issues related to that a long time ago on some UNIX
systems, and I want us to be conservative here.

On Sun, Feb 19, 2017 at 04:35:12PM +0100, Florian Weimer wrote:

* Greg KH:

quoted

On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:

quoted

We want to reject PTY devices from other namespaces as valid input to
the ttyname and ttyname_r functions, while still providing a hint to
callers that the device is, in fact, a PTY.  Christian Brauner wrote a
glibc patch for this:

  <https://sourceware.org/ml/libc-alpha/2017-01/msg00531.html>

It hard-codes the major PTY device number range.  Is this feasible?
Is it part of the stable userspace ABI for the TTY subsystem?

What major numbers are you using in the patch '2' and '3'?

I think there is just one patch, and the check looks like this:

  static inline int
  is_pty (struct stat64 *sb)
  {
    int m = major (sb->st_rdev);
    return (136 <= m && m <= 143);
  }

Ah, yes, 136-143 are the right ones, sorry, I was looking at the
"legacy" ones in devices.txt.

quoted

And yes,
major numbers are static and you should be fine to rely on them.  But
can't you test that the device is a pty to verify it?

It's not entirely clear what exactly a PTY descriptor should be for
ttyname.  Going forward, we only want to treat descriptors for PTY
devices which can be accessed using /dev/pts paths in the current
namespace as PTYs.  Christian's patch adds a separate error code for
the case where the descriptor is a PTY, but it comes from a different
namespace.

I'm concerned that some software out there assumes that if standard
input is a PTY according to ttyname, it is safe to chown it.  There
have been security issues related to that a long time ago on some UNIX
systems, and I want us to be conservative here.

Yeah, it's tricky.  And putting namespaces in the mix makes it messier.
Good luck!

greg k-h