At 110 kilograms, how far will it fly when it gets T-boned by a Hummer?

With all the hype surrounding Daikatana for years prior to its release, I don't understand how anyone could accuse it of being a game with bad advertising.

Guess what? noexec doesn't do jack shit on the majority of Linux systems, and does not prevent anybody from running a. You know why? /lib/ld-linux.so.2. (On x86_64, there's also /lib64/ld-linux-x86-64.so.2.)

This little file is in the ELF header of basically every single ELF-format Linux binary, under a field called INTERP (you can see this by dumping a binary with readelf). Yes, even though the executable is a binary, it calls an interpreter to handle all of the run-time module loading. By a really obnoxious design decision in Linux that laughs in the face of security, this library, despite its .so extension, is executable by design and by necessity on every single Linux system in the world. And by passing it the path to a program as its arguments, you can run any binary your little heart desires, whether the filesystem is mounted noexec or not. You can't possibly turn this behavior off unless you have a system with no dynamically linked binaries.

I don't see why this binary couldn't have added a check to see whether or not the program it's passed is mounted on a noexec filesystem, but to this day, it doesn't care.

It's also one of the reasons Solaris guys didn't take the idea of "Linux security" seriously for a very, very, very long time.

Not all is lost, though. SELinux can prevent the system from invoking this directly, outside the context of a freshly-executed process. It just relies on SELinux being properly set up on your systems.

This still doesn't completely fix the problem. On many (most?) systems, a user can still get around this by abusing LD_PRELOAD to preload a library with the same name and same symbols as one being loaded by some arbitrary program they're executing. Then, instead of compiling an executable binary, they're stuffing their code into a library instead and abusing the system's module loader to execute it. (This was the source of Oracle's SA10043 advisory, among others. It's the application's responsibility to validate LD_PRELOAD, especially where privilege escalation can occur.)

It's safest just to assume that if the user can run any arbitrary program the administrator put there, they can also run any arbitrary program the user put there.

It's basically a customization of Red Hat Enterprise Linux.