On Sun, 3 Nov 2002, Robert Watson wrote: > On Sun, 3 Nov 2002, Miguel Mendez wrote: > > > > 2) Security. Can LD_LIBRARY_PATH (or other mechanisms) > > > be used to deliberately subvert any of these programs? > > > (especially the handful of suid/sgid programs here) > > .. > > > > I can't come up right now with an idea of how exploiting LD_LIBRARY_PATH > > could be useful with any of these, but the possibility exists. OTOH, the > > recently added priviledge elevation feature should make it possible to > > have *no* setuid programs on a system, and have the kernel elevate > > priviledges for certain syscalls, based on the policy created by > > systrace. > > LD_LIBRARY_PATH is disabled for setuid binaries -- the kernel sets the > P_ISSETUGID flag, which is exported to userspace by issetugid(), which is > in turn checked by the rtld, which will refuse to observe that > environmental variable (and a number of others) as a result. We have > plenty of dynamically linked setuid binaires in the system already, and > it's not a problem.
Due to sucky latency, I didn't realize y fingers had typed the constant there incorrectly, that should read P_SUGID. That same protection also prevents debugging of processes following privilege downgrade, amongst other things. On the systrace issue -- I have lasting concerns about the race conditions present in fine-grained SMP and threaded systems, such as FreeBSD 5, or present in systems providing Linux clone() emulation. Neils has addressed some but not all of these concerns; until they are fully addressed, the race conditions there will remain a serious problem. When the scheduler activation work hits the main NetBSD tree, I would expect similar problems. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
