Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1583634 > unrolled thread

Re: Hard-coding PTY device node numbers in userspace

Started byGreg KH <gregkh@linuxfoundation.org>
First post2017-02-17 19:20 +0100
Last post2017-02-21 16:10 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Hard-coding PTY device node numbers in userspace Greg KH <gregkh@linuxfoundation.org> - 2017-02-17 19:20 +0100
    Re: Hard-coding PTY device node numbers in userspace Florian Weimer <fw@deneb.enyo.de> - 2017-02-19 16:40 +0100
      Re: Hard-coding PTY device node numbers in userspace Greg KH <gregkh@linuxfoundation.org> - 2017-02-21 16:10 +0100

#1583634 — Re: Hard-coding PTY device node numbers in userspace

FromGreg KH <gregkh@linuxfoundation.org>
Date2017-02-17 19:20 +0100
SubjectRe: Hard-coding PTY device node numbers in userspace
Message-ID<tbVip-7J5-15@gated-at.bofh.it>
On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:
> 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'?  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?

thanks,

greg k-h

[toc] | [next] | [standalone]


#1584162

FromFlorian Weimer <fw@deneb.enyo.de>
Date2017-02-19 16:40 +0100
Message-ID<tcBKF-Dv-5@gated-at.bofh.it>
In reply to#1583634
* Greg KH:

> On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:
>> 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.

[toc] | [prev] | [next] | [standalone]


#1585405

FromGreg KH <gregkh@linuxfoundation.org>
Date2017-02-21 16:10 +0100
Message-ID<tdkeL-4fZ-59@gated-at.bofh.it>
In reply to#1584162
On Sun, Feb 19, 2017 at 04:35:12PM +0100, Florian Weimer wrote:
> * Greg KH:
> 
> > On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:
> >> 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.

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web