From owner-freebsd-hackers Mon Oct 23 12:09:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAB18927 for hackers-outgoing; Mon, 23 Oct 1995 12:09:58 -0700 Received: from seattle.polstra.com (seattle.polstra.com [198.211.214.4]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA18912 for ; Mon, 23 Oct 1995 12:09:49 -0700 Received: by seattle.polstra.com (Smail3.1.28.1 #5) id m0t7SFB-000078C; Mon, 23 Oct 95 12:09 PDT Message-Id: Date: Mon, 23 Oct 95 12:09 PDT From: jdp@polstra.com (John Polstra) To: ache@freefall.freebsd.org Cc: freebsd-hackers@freebsd.org Subject: ld.so, LD_NOSTD_PATH, and suid/sgid programs Sender: owner-hackers@freebsd.org Precedence: bulk [Andrey - I am cc'ing this to the freebsd-hackers list, because I would like to get some additional opinions about this topic.] Nate Williams and I have been doing a lot of work on ld.so lately, so I noticed with interest the recently committed change to rtld.c: > ache 95/10/21 07:52:49 > > Modified: gnu/usr.bin/ld/rtld rtld.c > Log: > if uid != euid or gid != egid unsetenv("LD_NOSTD_PATH") too I don't think that this change was such a good idea. On one hand, it adds yet another little bit of strangeness to the behavior of ld.so for suid/sgid programs. On the other hand, I do not believe that it solves a security problem, or improves the security of ld.so in any way. The dynamic linker already had code to ignore a different environment variable, LD_LIBRARY_PATH, for suid and sgid programs. That was and is important, because it does solve a serious security problem. If the dynamic linker honored LD_LIBRARY_PATH for a suid or sgid program, then a user could cause any suid or sgid program to execute his own arbitrary code with elevated permissions. He could do that simply by setting LD_LIBRARY_PATH so that his own version of libc got used instead of the standard system library. That is why the dynamic linker ignores LD_LIBRARY_PATH when uid != euid or gid != egid. But LD_NOSTD_PATH is not the same. It does not constitute any security threat, as far as I can see. All LD_NOSTD_PATH does is to cause ld.so _not_ to look in the standard places (/usr/lib) for shared libraries. It does not and cannot allow a user to substitute his own code, and have it executed with elevated permissions. At worst, a user can cause ld.so to _fail_ by setting LD_NOSTD_PATH. But that, in itself, is no security threat. It doesn't give a user the ability to do anything that he couldn't already do some other way. 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. John Polstra jdp@polstra.com Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth