Re: Interesting suid problem

[Havoc Pennington <hp redhat com>]

Jeff Shipman - SysProg <jeff nmt edu> writes:
> I have a situation where I am using GTK as
> a frontend for a databse we have. Everything
> is fine except for the fact that I want to
> keep the database password secure. I do
> not want to store it in the program for
> obvious reasons so I thought I would save
> it in an external file and have the program
> read it on startup. The only decent way that
> I know of to do this have a special user
> which can read the file and have the program
> setuid to run as that user. However, gtk
> doesn't like being run setuid.

I don't see why the helper program would be that hard - especially
with GTK 2 and the g_spawn_* family of functions. You have a small
helper app, it spits the database password to a pipe, your app reads
the password from the pipe. Should be maybe 500 lines of code.

<lecture>

It's a good thing GTK doesn't let you do what you want, because the
result would be a giant security hole. The limitation here is not
imposed by GTK; it's imposed by security concerns.

If you don't care about security, then chmod 666 your file. If you do
care about security, you can't make a GUI application setuid. End of
story. There is nothing GTK can do about it - other than have the
safety check to keep you from doing the wrong thing.
 
> However, the only mention on this page of
> a helper program would require me to practically
> rewrite my entire application which is
> unacceptable.

Well, the fact that you don't have time to fix a bug, doesn't mean
that the bug goes away. You either have to fix the app, or have it be
a giant security hole. There isn't a magic solution.

> Otherwise, is there a way to work around this warning?

Sure, you can hack your local copy of GTK to contain a giant security
hole... it's a trivial patch to gtkmain.c. But it's easier (and
equivalent from a security standpoint) to chmod 666 the files you want
to access.

The warning is amazingly enough there for a reason. ;-) The warning is
a symptom, not the underlying problem. The underlying problem is the
security hole inherent in the application's design. Removing the
warning about the security hole doesn't mean the security hole is now
gone...

</lecture>

Havoc