> I think the reason it does not now is security, in the event that
> an suid executable is linked to it.
Right.
> If we added code to detect whether we are running in a suid environment
> and disallow use of the LIBGG_PATH variable in that case, then that might
> be a workable solution,
I'd rather don't do that. There were several infamous problems with telnetd/
login and ld.so that required horrible workarounds to fix.
The problem I have in mind particularly was to somehow place a .so file in
the to-be-attacked machines filesystem (e.g. by anonymous FTP upload
or just creating it in /tmp when you are already on as a normal user and
just want to become root) and then connecting via telnet to the box and
using the telnet extended protocol stuff to ask the telnetd to set
LD_PRELOAD to /whereever_the_.so_file_is.
This results in telnetd (which runs as root - real-root, not suid) to call
login to check the password , which will then call stuff like printf,
crypt(), getpass() or whatever, which is intercepted by the .so and
transformed to system("/bin/sh"); .
> P.S. Actually we'll be implementing some new features in the config file
> system probably for the 2.1 release, so doing that then would probably
> be good.
Yes - these features will be security-relevant anyway, so we will then have
to do some security checks internally anyway. Maybe I could be conviced to
include something like this, then, but usually I don't think it would be a
good idea.
Maybe we could add something like
pragma AllowOverrideConfigfile
to the commandset to allow for developers to disable that security feature
on machines that only they have access to for their convenience.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
