Date: Mon, 23 Oct 1995 18:41:19 -0700 From: David Greenman <davidg@Root.COM> To: Nate Williams <nate@rocky.sri.mt.net> Cc: ache@freefall.freebsd.org, freebsd-hackers@freebsd.org, John Polstra <jdp@polstra.com> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs Message-ID: <199510240141.SAA00275@corbin.Root.COM> In-Reply-To: Your message of "Mon, 23 Oct 95 18:10:45 MDT." <199510240010.SAA24195@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> >Can you see a security reason for disabling LD_NOSTD_PATH for suid/sgid >> >> >programs? If not, I think that the recent change should be removed from >> >> >rtld.c. >> >> >> >> In this case I keep in mind some shell script execution which calls >> >> setuid programs. By setiing LD_NOSTD_PATH user allows such >> >> programs easily fails, it is clear. >> >> >Why should a program which calls setuid programs fail in the first >> >place? If they are calling a setuid program it will still only look in >> >the 'normal' places for shlibs, which means they are safe. >> >> If user set LD_NOSTD_PATH it *NOT* look for normal places anymore. > >Then a system shared binary is *completely* and *utterly* useless. >Anyone who writes programs that writes shells scripts that depend on >system routines working with LD_NOSTD_PATH should deserve the error >messages they get. Why are we un-necessarily complicating the runtime >loader with this? > >Given this, I say the change is gratitious and un-needed. Any shell script which is suseptible to a security hole because a command failed to execute is broken. There are many reasons why things can fail ranging from no diskspace available to who knows what. I think Andrey's hack is an attempt to dam a river with a piece of tissue paper. The real problem is the shell script with the security hole, not the unpredictable nature of potential failures. My "vote" is to remove the hack. Regarding telnetd: I really think the proper solution to the problem is to do an inclusive env check, not an exclusive one. In other words, only specific environment variables should be allowed to be set (DISPLAY, TERM, a few others). It's really impossible to know what environment variables might lurk out there now and in the future - for instance, we check "TZ" in libc, and while I don't know how that could used to spoof telnetd/login, stranger things have happend. -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510240141.SAA00275>