We know the ability to run arbitrary binaries can be easily abused on Windows, so one of the preferred methods of blocking malware is to whitelist executables. This works fantastically for common desktop stuff; not so much for relatively advanced malware like Stuxnet (or an acne-pocked teenager pointing a copy of Metasploit at you). The problem is partly that, in a way, this is still blacklisting. What you're blacklisting is a few system calls. But if someone can mess around in a program's memory space, they might be able to make it load and execute a payload without resorting to those system calls you block. How about going a step further and whitelisting by system calls, instead of by executable files? Linux actually has a way of doing this. It's called seccomp, and Chrome uses it. The HTML renderer, and also the Flash plugin in recent versions, are only allowed to invoke the predefined set of system calls that they need in order to function. IIRC the way seccomp works involves building the whitelist into the application binary, or something along those lines. Aside from Chrome, not many applications use it. What about instead building a system wide profile of what programs can invoke what system calls? Instead of filtering specific ones, have: - A driver the intercepts every kernel function exported to userspace. - A database of which binaries can make which system calls. - Some kind of simple user interface that lets you set a learning time period before the system is locked down. - A means of resetting the database (backing it up in the process), so that the system can be reconfigured. So, like seccomp filtering, except designed for Windows and applied on a global basis. Is this workable? Theoretically possible? Completely half-baked?  Not sure what this ought to look like, I'll follow up with a post describing an idea for that.