He's talking about the halting problem, which isn't "2+2=3" impossible, but undecidable. Of course, the average engineer at Google has vastly more CS education than Schneier, would never have claimed to have solved the halting problem (or "program intent" as the AV people put it), and would have responded to this question more succinctly and accurately than Schneier did.
An infinite loop does not a virus make. With a multithreaded OS an infinite loop is not really a problem. Limiting resources to some defined level is a "solvable" problem.
The antivirus problem isn't a resource consumption problem. "The halting problem" is a CS synecdoche for the limitations of static analysis and the fundamental generality of what a "virus" is.
He's saying, "we mathematically figured out a long time that trying to look at a computer program and predetermine what it will do before running it is a task that reduces to the halting problem."
That this is a stupid way to look at the antivirus problem is besides the point here.
Sorry, that's a better explanation of what you meant but it's still not a problem.
You don't need to figure out what a program can do ahead of time if you limit what it can do at run time. You don't even need to let the user do anything at run time.
Lol, ok sorry I just had a someone is wrong on the internet moment. Which had nothing to you just the idea about the limits on what an OS could do. http://xkcd.com/386/
PS: I also just noticed that that was commic #386.
Allowing friendly programs to access resources but disallowing unfriendly ones is impossible, because it is impossible to distinguish between the two without some form of enforced signing that is impossible for the user to subvert(and who wants that?). And no, defaulting to reduced permissions for some programs is insufficient. People will still click "Ok, allow higher permissions" on programs if prompted.
What's the difference between 'rm -rf foo', for example, and 'run-virus'?
Not much, but nothing says the user needs to be able to type 'rm -rf foo'. Most people are used to OS that are designed to be fast and permissive, but you can code a defensive OS.
What sort of defensiveness do you think will work to effectively prevent -- to make up an example -- an application from popping up a fake login screen that asks them to enter the details, then mails the login info to the attacker and the program to all the victim's friends, without making the system unusable? Signed binaries where the signature describes the level of access might work if you don't allow it to be subverted by the user, but at the cost of essentially losing control over what you can run.i
I can't think of an especially usable uber-paranoid defensive system, although I'd definitely love to be proven wrong. Essentially, the problem isn't a totally technological one. The core of the problem is that the user can effectively be convinced to be their own attacker.
Comments
He's talking about the halting problem, which isn't "2+2=3" impossible, but undecidable. Of course, the average engineer at Google has vastly more CS education than Schneier, would never have claimed to have solved the halting problem (or "program intent" as the AV people put it), and would have responded to this question more succinctly and accurately than Schneier did.
An infinite loop does not a virus make. With a multithreaded OS an infinite loop is not really a problem. Limiting resources to some defined level is a "solvable" problem.
The antivirus problem isn't a resource consumption problem. "The halting problem" is a CS synecdoche for the limitations of static analysis and the fundamental generality of what a "virus" is.
He's saying, "we mathematically figured out a long time that trying to look at a computer program and predetermine what it will do before running it is a task that reduces to the halting problem."
That this is a stupid way to look at the antivirus problem is besides the point here.
Sorry, that's a better explanation of what you meant but it's still not a problem.
You don't need to figure out what a program can do ahead of time if you limit what it can do at run time. You don't even need to let the user do anything at run time.
You are arguing with the wall. I'm just explaining what Schneier meant by "2+2=3".
Lol, ok sorry I just had a someone is wrong on the internet moment. Which had nothing to you just the idea about the limits on what an OS could do. http://xkcd.com/386/
PS: I also just noticed that that was commic #386.
Allowing friendly programs to access resources but disallowing unfriendly ones is impossible, because it is impossible to distinguish between the two without some form of enforced signing that is impossible for the user to subvert(and who wants that?). And no, defaulting to reduced permissions for some programs is insufficient. People will still click "Ok, allow higher permissions" on programs if prompted.
What's the difference between 'rm -rf foo', for example, and 'run-virus'?
Not much, but nothing says the user needs to be able to type 'rm -rf foo'. Most people are used to OS that are designed to be fast and permissive, but you can code a defensive OS.
What sort of defensiveness do you think will work to effectively prevent -- to make up an example -- an application from popping up a fake login screen that asks them to enter the details, then mails the login info to the attacker and the program to all the victim's friends, without making the system unusable? Signed binaries where the signature describes the level of access might work if you don't allow it to be subverted by the user, but at the cost of essentially losing control over what you can run.i
I can't think of an especially usable uber-paranoid defensive system, although I'd definitely love to be proven wrong. Essentially, the problem isn't a totally technological one. The core of the problem is that the user can effectively be convinced to be their own attacker.