Tetsuo Handa wrote: >> This reasoning makes no sense. If you are *sure* that it is a malicious >> process, then either kill it, or block its access. Why is it necessary >> to screw around with letting it exec something other than what it asked >> for, when you could do something much stronger if you are *sure*? >> > If I kill the hijacked process, I can't get information from the process. > For example, I can get environment variable information using something like > That is beside the point. The main action I advocated was to exec() nothing at all, and return whatever error code you want. Killing the process was just an example of another possible action.
>> I see no room for substituting /bin/true for the original exec request. >> It has all of the negative consequences of just blocking the exec, and >> fewer advantages. >> > I tested that I can stop CPU consumption caused by Samba's trans2open exploit. > If I utilize the trigger (i.e. execute something other than /bin/true ), > I can do more defense action. > This is an advantage that can't be obtained by just killing the process. > I still see no reason to ever use the "/bin/true" technique. Why run a program with no side effects? Let's not, and just say we did :-) Just don't run anything, and return the error code that /bin/true would have returned. I still object to lying to the program by returning success instead of failure, EPERM, or something like that. It at least gives the program an opportunity to fail gracefully if it was not actually malicious. Lying to the program and returning success is suitable if you are trying to forensically determine what the malware will do, but if that is your objective, then running the malware in a honeypot on a virtual machine is a better choice. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
