Hello. > 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. If I have captured a malware and I want to analyze it, I should prepare a honeypot on a virtual machine.
I want a server run a regular service when the server is not receiving attacks. The server is not prepared for a honeypot. When the server is receiving attacks, I don't want the server stop the regular service because of CPU consumption. Both "kill the process when execution of /bin/sh is requested" and "execute /bin/true when execution of /bin/sh is requested" can stop CPU consumption, but "execute a program specified by the administrator when execution of /bin/sh is requested" can do "stop CPU consumption (if we want to stop CPU consumption)" and "observe what the attacker will do (if we want to collect information)" and "react without external monitoring daemon (if we want to do defense action)" and "print warning message (if we want to notify the user or attacker)" and so on. > Killing the process was just an example of another possible action. Executing /bin/true is just an example of possible actions. If executing /bin/true (to silently terminate the process) is a bad thing, I think killing the process (to silently terminate the process) is a bad thing too. > Just don't run anything, and return the error code that /bin/true would have > returned. Just returning the error code and continue the process is a bad thing too because the server stops the regular service because of CPU consumption. > I still see no reason to ever use the "/bin/true" technique. The reason I run something is to terminate the process (to avoid CPU consumption triggered by infinite execve() loop). Just killing the process can avoid CPU consumption, but I think replacing the process with some other program is more flexible. - 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
