[ On Thursday, January 1, 2004 at 21:22:47 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> On Thu, Jan 01, 2004 at 02:43:50PM -0500, Greg A. Woods wrote:
> > 
> > If you don't have the rights on some machine to change /etc/resolv.conf
> > then you shouldn't have the right to tell the resolver to use some other
> > configuration, even if it is only rope for your own execution.
> 
> Why ?

For all of the same reasons HOSTALIASES is dangerous and should not be
supported in the way it currently is (even with the hack to avoid having
setuid programs use it), and then some.

Also for the same reason that if you don't have the root password (or
equivalent) then you shouldn't be mucking with any system configuration
files!

Of course the better way, instead of simply outlawing the whole idea of
such a feature, is to move the direct control over an alternate file out
of libc and thus give the application the ability do decide whether it's
"safe" to allow the user to choose to use an alternate config file,
perhaps even choosing specific circumstances when to allow or deny the
user the ability to control such a feature.

Once you do that it's possible to use any number of various mechanisms
to export this control to the user, including environment variables if
they are appropriate for the application in question.

This way "privileged" programs (and especially set-ID programs) can be
written such that they will only use an alternate file if the invoking
user has the appropriate privileges.  Or not, as the author chooses.

Every instance I can think of where an environment variable has been
used by a libc function to affect its behaviour has resulted in one kind
of security problem or another, particularly when the semantics are for
it to specify a filename and always when the function in question might
be called from a set-ID program.  If you recall the previous discussions
about $HOSTALIASES you'll remember there was far more than just one
security problem with it.

HOSTALIASES and the proposed RESOLV_HOST_CONF variable (as it's known in
an existing implementation) are also dangerous because they might make
it possible to spoof DNS to privileged programs (even if all set-ID
programs ignore their values).

If you look into the discussions that have occurred over these issues
for many years now you'll find statements such as this excellent one:

    Last time I looked at possibilities for exploits of environment
    variables on setuid programs (or via telnetd), I came to the
    conclusion that virtually all environment variables, even the "safe"
    (and sometimes necessary) ones, were potentially exploitable.

(I'll leave it unattributed because I don't really think it matters who
said it using exactly those words.)

The invoking user's environment can never be trusted by any set-ID
program, and placing code in libc/libresolv that makes use of any
environment variable is just asking for some very serious trouble.

GNU Libc has already suffered from all these issues, tried to fix/avoid
them in stupid ways, suffered again, and so on.  Do you want to repeat
this sad history?

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>