Jens Knoell wrote: > > An execve() wrapper would help to protect legitimate programs against > > inadvertantly executing malicious code, but it won't restrict what > > malicious code can execute, as malicious code can just bypass the > > execve() function. > > *nods* that's the idea. The legitimate program would be the webserver, and > presumably legitimate CGI's (which would be spawned via suexec). CGI's > commonly won't be able to write to the CGI directory, which I intend to make > the _only_ directory from where the webserver itself can execute binaries. In which case, an execve() wrapper should suffice; glibc defines execve as a weak symbol, so overriding it in an external library would still affect glibc functions which use it. OTOH, putting the temp directories on a separate filesystem which is mounted with the noexec flag will also work, and may be more robust as the restriction is implemented by the kernel rather than in user space. > > Nor will it prevent the execution of malicious code which is stored as > > a shared library rather than an executable. > > I'd think if someone manages to get a library onto the machine I have a bigger > problem at hand. Libraries should only be writeable by root, and if someone > has root on the machine it's too late... I was referring to the situation where, rather than upload a malicious executable, they upload a malicious shared library into the temp directory then use e.g. "LD_PRELOAD=/tmp/malware.so /bin/true". -- Glynn Clements <glynn.clements@xxxxxxxxxx> - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
