glibc: pt_chown setuid going away by default

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

glibc: pt_chown setuid going away by default

Mike Frysinger
tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things will
happen and it's (probably) all your fault

when you run grantpt(), glibc attempts to set up your pty with correct
ownership & permissions.  it does so by executing a setuid helper called
pt_chown as needed.  we all know setuid==bad, so let's do something about it.

this system is a throw back to the bad old bsd pty days where you had a ton of
pre-allocated nodes in /dev/ named pty??.  since the user has requested a new
pty, the system had to make sure it had correct permissions before giving it
back (it might be the default of root:root, or it might have the previous
user's settings which would be super bad).  this system sucks for many
reasons.

with Linux, we have devpts mounted at /dev/pts/ which provides dynamic UNIX 98
ptys via the /dev/ptmx control node.  the kernel knows that when you request a
new pty, the sane thing is to set the default uid/gid to your own process's
uid/gid.  it even goes further and allows you to specify (at mount time)
default gid/permissions.

with openrc (and in baselayout-1.12, but i'm pretty sure it's been this way
for even longer), our default mount uses gid=5 (the tty group) and mode=620
(what we want).  that means when a new pty is requested, the kernel
automatically sets the ownership of the new file to the process's uid and the
mounted group setting (tty), as well as setting the perms to 620.

back to glibc, when you call grantpt(), it checks the current uid/gid/mode.  
if they all match what it expects (and it should with our default devpts mount
opts), it returns w/out doing any real work (like calling the setuid pt_chown
helper).  that means this binary is sitting around with setuid perms for no
good reason.

i plan on updating the latest glibc to add USE=suid.  in pkg_preinst and
ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5.  if
it doesn't find one, i'll have it call `die`.  if the bsd pty scenario wasn't
long dead, and the devpts option didn't have gid=/mode= options, then it might
be reasonable to have it warn and do `chmod +s`.  but i can't think of any
legitimate reasons for not using devpts & mounting it correctly.  this is the
right answer even in the embedded world.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Paweł Hajdan, Jr.
On 4/9/13 10:15 PM, Mike Frysinger wrote:
> i plan on updating the latest glibc to add USE=suid.  in pkg_preinst and
> ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5.  if
> it doesn't find one, i'll have it call `die`.  if the bsd pty scenario wasn't
> long dead, and the devpts option didn't have gid=/mode= options, then it might
> be reasonable to have it warn and do `chmod +s`.  but i can't think of any
> legitimate reasons for not using devpts & mounting it correctly.  this is the
> right answer even in the embedded world.

+1

I have it disabled already on some of my systems using suidctl.

I was going to suggest making that change some time ago - great to hear
it's being done. Thanks for working on this!

Paweł


signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Rich Freeman
In reply to this post by Mike Frysinger
On Wed, Apr 10, 2013 at 1:15 AM, Mike Frysinger <[hidden email]> wrote:
> tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things will
> happen and it's (probably) all your fault

So, who is this directed to?  If this is to anybody who uses Gentoo,
then at best this should be a place to hash out the contents of the
news item.  We don't expect Gentoo users to read -dev.  Certainly the
maintainers of anything that mounts /dev/pts
(OpenRC/SystemD/baselayout?) should take heed.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
On Wednesday 10 April 2013 14:56:26 Rich Freeman wrote:
> On Wed, Apr 10, 2013 at 1:15 AM, Mike Frysinger <[hidden email]> wrote:
> > tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad things
> > will happen and it's (probably) all your fault
>
> So, who is this directed to?

any dev who maintains systems that handle initial mounting, or knows of random
edge cases in the tree that might run into this.  i can't exactly grep our
entire code base looking for devpts mounters.

> If this is to anybody who uses Gentoo,
> then at best this should be a place to hash out the contents of the
> news item.  We don't expect Gentoo users to read -dev.

users will be informed of the problem when the ebuild fails and then can
trivially resolve it at that point.  this should impact very few (if any)
users, so i don't think a news item makes sense.

> Certainly the
> maintainers of anything that mounts /dev/pts
> (OpenRC/SystemD/baselayout?) should take heed.

the maintainers are reading -dev
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Duncan-42
Mike Frysinger posted on Wed, 10 Apr 2013 15:32:40 -0400 as excerpted:

> On Wednesday 10 April 2013 14:56:26 Rich Freeman wrote:
>> On Wed, Apr 10, 2013 at 1:15 AM, Mike Frysinger <[hidden email]>
>> wrote:
>> > tl;dr: make sure your /dev/pts is mounted correctly w/gid=5 or bad
>> > things will happen and it's (probably) all your fault
>>
>> So, who is this directed to?

>> If this is to anybody who uses Gentoo,
>> then at best this should be a place to hash out the contents of the
>> news item.  We don't expect Gentoo users to read -dev.
>
> users will be informed of the problem when the ebuild fails and then can
> trivially resolve it at that point.  this should impact very few (if
> any) users, so i don't think a news item makes sense.

/This/ user would have been affected.  I guess the GID bit wasn't in the
shipped fstab back in 2004 when I setup the system, or in any case, it
wasn't there until I just added it last nite, based on this thread.

Of course, /this/ user reads dev, too, exactly because it does give me a
heads-up on such things, as well as a bit of the reasoning (and often
some discussion) behind it.

I'd argue that any gentooer that takes their gentooing sysadmin
responsibilities seriously really should read -dev for exactly that
reason, but I suppose in practice we're actually lucky that most don't,
or the list would either be too busy to follow (and get anything else
done) or would have to be read-only for ordinary users.

But you're right in that if I hadn't read it here, the die and I assume a
reasonable die message would have informed me what action I needed to
take to fix the problem.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

James Cloos-9
In reply to this post by Mike Frysinger
>>>>> "MF" == Mike Frysinger <[hidden email]> writes:

MF> this should impact very few (if any)
MF> users, so i don't think a news item makes sense.

It will impact everyone who has /dev/pts in fstab(5).

I doubt that any say gid=5.

I don't remember why this box has it in fstab; it looks like it always did.

The backup of my (now dead) laptop also has such an entry.  The rcs log
for that one shows that it got added in late '03, and not manually.

I imagine therefore that it is not all that uncommon.

-JimC
--
James Cloos <[hidden email]>         OpenPGP: 1024D/ED7DAEA6

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
On Thursday 11 April 2013 11:43:59 James Cloos wrote:
> >>>>> "MF" == Mike Frysinger <[hidden email]> writes:
> MF> this should impact very few (if any)
> MF> users, so i don't think a news item makes sense.
>
> It will impact everyone who has /dev/pts in fstab(5).

don't do that.  delete the line.

> I doubt that any say gid=5.
>
> I don't remember why this box has it in fstab; it looks like it always did.
>
> The backup of my (now dead) laptop also has such an entry.  The rcs log
> for that one shows that it got added in late '03, and not manually.

baselayout has not included devpts in /etc/fstab since 26 Nov 2001 and even
then, it was commented out

http://sources.gentoo.org/baselayout/branches/baselayout-1_12/etc/fstab?view=log
http://sources.gentoo.org/baselayout/branches/rc-
scripts-1_6/etc/fstab?view=log

the oldest tag we have is baselayout-1.11.15 (released 22 Apr 2006), and it
doesn't include it.

the oldest tarball i have is baselayout-1.11.8 (released 15 Dec 2004) as
that's when i took over releasing things, and it doesn't include it either.
it hasn't been added since that release.

so i stand by my statement that very few people will be impacted by this.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Duncan-42
Mike Frysinger posted on Thu, 11 Apr 2013 12:49:00 -0400 as excerpted:

> On Thursday 11 April 2013 11:43:59 James Cloos wrote:
>> >>>>> "MF" == Mike Frysinger <[hidden email]> writes:
>> MF> this should impact very few (if any)
>> MF> users, so i don't think a news item makes sense.
>>
>> It will impact everyone who has /dev/pts in fstab(5).
>
> don't do that.  delete the line.

I wonder if I added my devpts fstab entry (if as you say it wasn't an
automated add) some time ago, when there was some security related hubbub
over it, as significantly, my fstab entry has nosuid, noexec, while the
default for it in /etc/init.d/devfs does not.

My fstab devpts entry also has noauto, but that's likely simply due to it
being an fstab entry...

Regardless, that's at least two gentooers with installations dating from
the early 00s that have reported having the (GID-less) entry in fstab
now, so I strongly suspect it's going to affect more users, at least long-
time users, than you thought.  It may in fact affect the majority of
users from that era... anyone who hasn't manually removed that entry from
fstab over the years.

You mention it wasn't in the old baselayout/openrc tarballs.  What about
the early stages?  Perhaps that's where it came from?  Anyone with 2004.x
vintage stage tarballs around to check?

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Maxim Kammerer-2
In reply to this post by Mike Frysinger
On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger <[hidden email]> wrote:
> i plan on updating the latest glibc to add USE=suid.  in pkg_preinst and
> ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5.  if
> it doesn't find one, i'll have it call `die`.

What about chroot builds? I have /dev/pts bind-mounted from the (old)
host filesystem into chroot, yet pt_chown has its suid bit happily
disabled in deployed build since long time ago.

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
On Friday 12 April 2013 02:50:20 Maxim Kammerer wrote:
> On Wed, Apr 10, 2013 at 8:15 AM, Mike Frysinger <[hidden email]> wrote:
> > i plan on updating the latest glibc to add USE=suid.  in pkg_preinst and
> > ROOT==/, the ebuild will read /proc/mounts for a devpts line with gid=5.
> > if it doesn't find one, i'll have it call `die`.
>
> What about chroot builds? I have /dev/pts bind-mounted from the (old)
> host filesystem into chroot, yet pt_chown has its suid bit happily
> disabled in deployed build since long time ago.

i don't know what you mean.  if the ebuild detects devpts being mounted and
the mount is incorrect, it will die.  if you don't have devpts mounted at all,
then it assumes you know what you're doing.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Maxim Kammerer-2
On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger <[hidden email]> wrote:
> i don't know what you mean.  if the ebuild detects devpts being mounted and
> the mount is incorrect, it will die.  if you don't have devpts mounted at all,
> then it assumes you know what you're doing.

What I am saying is that you make no distinction between build
environment and deployment environment. Quite a few users build their
Gentoo systems in a chroot. In that case, whole /dev, or its portions
(including /dev/pts) can be bind-mounts from the host filesystem, and
/dev/pts does not need to have the correct permissions. However, you
*would* see such a bind-mount as a devpts mount in /proc/mounts. So
why not print a warning — what's the point of dying in pkg_preinst?

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Gilbert-2
On Fri, Apr 12, 2013 at 1:20 PM, Maxim Kammerer <[hidden email]> wrote:

> On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger <[hidden email]> wrote:
>> i don't know what you mean.  if the ebuild detects devpts being mounted and
>> the mount is incorrect, it will die.  if you don't have devpts mounted at all,
>> then it assumes you know what you're doing.
>
> What I am saying is that you make no distinction between build
> environment and deployment environment. Quite a few users build their
> Gentoo systems in a chroot. In that case, whole /dev, or its portions
> (including /dev/pts) can be bind-mounts from the host filesystem, and
> /dev/pts does not need to have the correct permissions. However, you
> *would* see such a bind-mount as a devpts mount in /proc/mounts. So
> why not print a warning — what's the point of dying in pkg_preinst?
>

Do you have a reason for not having /dev/pts mounted with gid=5 on the
system hosting the chroot environment?

Calling die is much more likely to save users systems than an ewarn.

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

James Cloos-9
In reply to this post by Mike Frysinger
>>>>> "MF" == Mike Frysinger <[hidden email]> writes:

>> It will impact everyone who has /dev/pts in fstab(5).

MF> don't do that.

*I* didn't.

I don't know /what/ added it, but something did.  With noauto, just like
the other reported case.

It shouldn't matter how rare it is though.  A general announcement won't
hurt anyone.

-JimC
--
James Cloos <[hidden email]>         OpenPGP: 1024D/ED7DAEA6

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
In reply to this post by Maxim Kammerer-2
On Friday 12 April 2013 13:20:11 Maxim Kammerer wrote:

> On Fri, Apr 12, 2013 at 7:22 PM, Mike Frysinger <[hidden email]> wrote:
> > i don't know what you mean.  if the ebuild detects devpts being mounted
> > and the mount is incorrect, it will die.  if you don't have devpts
> > mounted at all, then it assumes you know what you're doing.
>
> What I am saying is that you make no distinction between build
> environment and deployment environment. Quite a few users build their
> Gentoo systems in a chroot. In that case, whole /dev, or its portions
> (including /dev/pts) can be bind-mounts from the host filesystem, and
> /dev/pts does not need to have the correct permissions. However, you
> *would* see such a bind-mount as a devpts mount in /proc/mounts. So
> why not print a warning — what's the point of dying in pkg_preinst?
unless you have a good reason for having the host devpts being mounted wrong,
i'm not inclined to support this.  every major distro that matters that i know
of does it this way and has for a long time: Debian, Ubuntu, Fedora, Gentoo.

if it encourages people to fix their host distro to also not suck, well that's
just a bonus.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
In reply to this post by Duncan-42
On Thursday 11 April 2013 22:19:40 Duncan wrote:

> Mike Frysinger posted on Thu, 11 Apr 2013 12:49:00 -0400 as excerpted:
> > On Thursday 11 April 2013 11:43:59 James Cloos wrote:
> >> >>>>> "MF" == Mike Frysinger <[hidden email]> writes:
> >> MF> this should impact very few (if any)
> >> MF> users, so i don't think a news item makes sense.
> >>
> >> It will impact everyone who has /dev/pts in fstab(5).
> >
> > don't do that.  delete the line.
>
> I wonder if I added my devpts fstab entry (if as you say it wasn't an
> automated add) some time ago, when there was some security related hubbub
> over it, as significantly, my fstab entry has nosuid, noexec, while the
> default for it in /etc/init.d/devfs does not.
>
> My fstab devpts entry also has noauto, but that's likely simply due to it
> being an fstab entry...
>
> Regardless, that's at least two gentooers with installations dating from
> the early 00s that have reported having the (GID-less) entry in fstab
> now, so I strongly suspect it's going to affect more users, at least long-
> time users, than you thought.  It may in fact affect the majority of
> users from that era... anyone who hasn't manually removed that entry from
> fstab over the years.
>
> You mention it wasn't in the old baselayout/openrc tarballs.  What about
> the early stages?  Perhaps that's where it came from?  Anyone with 2004.x
> vintage stage tarballs around to check?
stages get their files from baselayout/openrc.  they don't generate them
themselves.

Robin found even older baselayout releases for me.  baselayout-1.8.6.12
(released Nov 2011) and newer don't contain any mention of devpts.

i don't know about 2004 releases, but i have stage tarballs i built in Oct
2005 using gcc-2.95 and they're exactly what i expect -- they match the
baselayout install.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
In reply to this post by James Cloos-9
On Friday 12 April 2013 15:41:55 James Cloos wrote:
> >>>>> "MF" == Mike Frysinger <[hidden email]> writes:
> >> It will impact everyone who has /dev/pts in fstab(5).
>
> MF> don't do that.
>
> *I* didn't.

that you remember.  i think it's more likely you copy & pasted some line a
long time ago than baselayout modified it for you.

two people who have installs that are a decade old doesn't incline me to write
a news entry.  not when the ebuild itself contains a sanity check that
triggers exactly as needed and includes an error message explaining things.  
we aren't talking about an upgrade here that will silently & accidentally
break your box on next boot (like udev & friends), or will break running
programs (like SONAME bumps, although that's a much less of a problem now that
portage handles things automatically).
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Jeroen Roovers-3
On Fri, 12 Apr 2013 16:08:10 -0400
Mike Frysinger <[hidden email]> wrote:

> that you remember.  i think it's more likely you copy & pasted some
> line a long time ago than baselayout modified it for you.

Exactly, but where did that come from?

> two people who have installs that are a decade old doesn't incline me
> to write a news entry.  not when the ebuild itself contains a sanity
> check that triggers exactly as needed and includes an error message
> explaining things. we aren't talking about an upgrade here that will
> silently & accidentally break your box on next boot (like udev &
> friends), or will break running programs (like SONAME bumps, although
> that's a much less of a problem now that portage handles things
> automatically). -mike

I have been looking through old copies of the Handbook in the last
hour, assuming the fstab entry may have been included there at some
point. I haven't done anything like a thorough search, but I assume it
may have slipped into the handbook at some point and was later removed
(as some CVS log entries from 2004 seem to suggest).


     jer

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

James Cloos-9
>>>>> "JR" == Jeroen Roovers <[hidden email]> writes:

JR> On Fri, 12 Apr 2013 16:08:10 -0400
JR> Mike Frysinger <[hidden email]> wrote:

>> that you remember.  i think it's more likely you copy & pasted some
>> line a long time ago than baselayout modified it for you.

JR> Exactly, but where did that come from?

If it didn't come from baselayout or openrc, the most likely scenario is
some gui crud.

I probably looked through the list of apps once I got a menu tree based
on .desktop files added to my wm.  And with sudo(8) configured for
convenience, if I ran an app which edits fstab(5), it would not have
needed to ask for my sudo passwd to work.

And gnome seems to prefer fully to rewrite files in their own quirky
style.  Rather than just making changes.

(Rewrites like that are why I tend to chattr+i a lot of files in /etc.)

-JimC
--
James Cloos <[hidden email]>         OpenPGP: 1024D/ED7DAEA6

Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Mike Frysinger
In reply to this post by Jeroen Roovers-3
On Saturday 13 April 2013 13:06:04 Jeroen Roovers wrote:
> On Fri, 12 Apr 2013 16:08:10 -0400 Mike Frysinger wrote:
> > that you remember.  i think it's more likely you copy & pasted some
> > line a long time ago than baselayout modified it for you.
>
> Exactly, but where did that come from?

probably worthwhile to track down to better understand, but i don't think the
answer will change the result

> > two people who have installs that are a decade old doesn't incline me
> > to write a news entry.  not when the ebuild itself contains a sanity
> > check that triggers exactly as needed and includes an error message
> > explaining things. we aren't talking about an upgrade here that will
> > silently & accidentally break your box on next boot (like udev &
> > friends), or will break running programs (like SONAME bumps, although
> > that's a much less of a problem now that portage handles things
> > automatically).
>
> I have been looking through old copies of the Handbook in the last
> hour, assuming the fstab entry may have been included there at some
> point. I haven't done anything like a thorough search, but I assume it
> may have slipped into the handbook at some point and was later removed
> (as some CVS log entries from 2004 seem to suggest).
it's at times like this i wish we had a git repo.  `git log -p -C -M` is great
at tracking this sort of stuff down.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glibc: pt_chown setuid going away by default

Rich Freeman
On Wed, Apr 17, 2013 at 2:35 PM, Mike Frysinger <[hidden email]> wrote:
> it's at times like this i wish we had a git repo.  `git log -p -C -M` is great
> at tracking this sort of stuff down.

I don't want to hijack this thread, but I don't believe we have a
tracker for the migration of docs / website / etc to git.  Is there
simply not interest?  I'm not sure what complexities exist compared to
the portage migration.

Rich

12