I am not our Fearless Leader, but hopefully my opinions (and my arguments) still have some weight, at least regarding security issues. Basically, I think that normal users shouldn't be allowed to influence which libraries a setuid program is loaded with. I don't really care if LD_PRELOAD is completely disabled for setuid binaries or if it only enabled when uid == root || uid == whatever-the-setuid-program-is-setuid-to, but I am stongly against having it enabled all the time. First, I really doubt that allowing LD_PRELOAD to work on setuid binaries is 'standard Unix practice'. It's certainly not standard Linux practice, at least. And unless my memory of my SunOS days is flawed, SunOS didn't allow that either. And I somehow doubt that the *BSD have enabled that 'feature'. Maybe someone can check? I've read elsewhere about Ulrich's suggestion that libraries in /lib and /usr/lib should be considered secure. There are many problems with that... one of the biggest being precisely that it's just someone's idea. (Even if that someone happens to be a good coder.) Read the FSSTND. It says "the distribution installs its libraries in /usr/lib, or in /lib if they're needed by programs in /bin or /sbin. The local sysadmin install libraries in /usr/local/lib." Absolutely no distinction is made between 'secure' and 'non-secure' libraries. (I only briefly skimmed through the FHS, but I don't think there's been any change with respect to /lib and /usr/lib.) More important, ask your local sysadmin. Ask whether he thinks there's a trusted/untrusted distinction between /usr/lib and /usr/local/lib, say. Ask whether he places 'trusted' libraries in a different directory than untrusted ones. I'm certain you'll get a blank look at first, and then a "no" as your answer. I worked during my studies as assistant to the sysadmins of the McGill EE lab. When we needed to install a new setuid program, we looked (a bit) at the code, we looked at the reputation of the author... and we looked at what libraries it wanted to link with. Basically, when the program wanted to link in anything else in addition to libc and the X11 libs, we went and looked at those libraries too. The point is, we placed no restrictions on *installing* libraries, but we didn't *link* setuid programs with non-trusted libraries. The choice was done at link-time. And I suspect that's how the average Unix shop operates. Silently enabling LD_PRELOAD to work on setuid binaries breaks that (perfectly good) security model completely. But that's precisely the security model that's (implicitly) contained in the FSSTND, and in the head of the average Linux sysadmin. I'm not saying that the concept of 'trusted' libraries (or of a 'trusted lib directory) is a bad idea. But this just wasn't in Unix when shared libraries were added. So when you want to introduce such a concept *later*, the thing you *do not* do is assume that libraries installed in some (arbitrary) pre-existing directories are there because they were trusted. What you do is assume that libraries in the pre-existing lib directories are *unstrusted*, define a method of specifying trusted libraries (one that doesn't pick up as 'trusted' standard directories that pre-existed your idea of 'trusted lib directories'), and you educate the sysadmin about *that*. So it Ulrich wants to introduce this new concept of 'trusted' libraries, he should either extend the syntax of /etc/ld.so.conf to allow specifying 'trusted' directories (with the default being *unstrusted*) or mandate a non-existing directory (say, /usr/lib/trusted and /lib/trusted) as trusted, or maybe say that when the setuid bit it set on a library, the library is considered trusted. But imposing this idea that /lib and /usr/lib are trusted when not everyone saw them like that is just the wrong way to go. Furthermore, I also cannot think of a single good reason why normal users should be allowed to influence the libraries a setuid program is loaded with. Writing a secure setuid program is already hard enough... A (potentially hostile) user already has control over a setuid program's environment variables, standard input, command line, pre-existing open file descriptors. He can starve the program of memory, of disk space, or of file descriptors, and he can 'reconfigure' the parts of the directory hierarchy where he has write permission) and make them point to other, more interesing parts of the hierarchy (like, say /etc or /root) through symlinks. Do we really want to give crackers another way to 'tickle' bugs out of setuid programs? In fact, if we enable LD_PRELOAD on setuid programs, I suspect the main users will be crackers. I'd rather not have us diverge of the upstream source if we can avoid if, but I think that here we have a good reason for doing so. Therefore, could the 'LD_PRELOAD works on setuid binaries' feature please be disabled, at least for 'normal' users? Thank you, Christian Debian Security Officer. PS You're of course more than welcome to use the arguments contained here to convince Ulrich/other libc-hackers people, but please don't forward this email, at least not without asking me first. I'm not sure if Ulrich would find my email inflammatory... and I wouldn't want that to happen.
Attachment:
pgpL9AyGyzVxx.pgp
Description: PGP signature