Re: Claimed vulnerability in GTK_MODULES

[Owen Taylor <otaylor () REDHAT COM>]

Kris Kennaway <kris () FreeBSD org> writes:

> On Wed, Jan 03, 2001 at 10:40:33AM -0500, Owen Taylor wrote:
> > What follows is the official GTK+ team position on this matter.  (It
> > can be found at http://www.gtk.org/setuid.html as well.)  The summary
> > is that we don't consider it a problem because writing set[ug]id
> > programs with a GUI toolkit is simply a bad idea and not supported for
> > GTK+.
>
> Why not force the issue and abort in GTK startup if issetugid() (for
> those platforms which have it)?

I do plan on adding some sort of check like this in the next
stable release of GTK+ to help people avoid making this mistake.

The exact check is a little tricky - issetugid() can't be used
because it is too strict - it would disallow programs that drop
privileges before initializing GTK+, because they might
conceivably have acquired access to restricted resources.

While this level of strictness isn't ridiculous, it would prevent
current, arguably valid uses of GTK+. And if the programmer
really wants to create a security hole, they can do it even with
a issetugid() check. issetugid() is intended for different
circumstances.

What we what is a check that catches the cases where the
programmer is definitely doing something wrong. A simple:

 (getuid() != geteuid() || getgid() != getegid())

check is closer to this, though it doesn't handle the case of
POSIX saved IDs properly. On Linux, it is possible to use
getresuid() to make the check somewhat more thorough. [1]

Regards,
                                        Owen


[1] That still doesn't handle setreuid (geteuid(), -1), but in
    the end, if you are writing setuid programs, you do need to
    know something about the dangers.