So, I was wrong. Schneier's analysis wasn't based on the halting problem, but an even sillier analysis by Fred Cohen's U Cincinnati thesis that found it necessary to reach all the way to Godel to come to the conclusion that "it is impossible to write a program that determines whether another program will function correctly".
Virus study is fringe computer science. When there are vast tracts of solid systems research across operating systems, compilers, and symbolic analysis to cite, reaching for the goofy fringe stuff is not a credibility enhancer.
I don't think Schneier has shown he has anything useful to say about Chrome OS yet.
Does it matter what he has to say though? The thing isn't even out yet. His speculations are about as good as anyone's at this point and, in the end, it really is up to you to decide what to call bs on, whether it came from a celebrity's mouth or not.
(1) The "virus-free OS" meme, which is pernicious and displaces reasonable thinking about system security, which is something that everyone --- Apple, Linux, Microsoft, and Google included --- are working hard on.
(2) The guru phenomenon, where people embed themselves into the industry consciousness and become fonts for random meaningless sound bites.
Probably good to call me out for obsessing about it, though I'll note that I feel comfortable babbling about it on Hacker News because I "know" you people, and would be less comfortable talking to a reporter about it.
What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build.
You can write software that deals with reasonable levels of memory corruption when it's operating. As in this will survive if no more than X bits are flipped per second in either the source code or RAM.
Yes, it's slow and expensive to create and operate, but it is also possible. Yet his argument is based on the assumption that you need a virus scanner for some reason. I know it's hard and expensive to create clean systems, but that's a long way from impossible.
PS: What I love about Hacker News is talking with people who understand some things and a far deeper level than I do, and are also willing to listen to a reasonable argument.
What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build.
A capability system would be a lot harder to completely corrupt. Sandboxing can limit damage to manageable compartments, and enable the system to roll back without user intervention. I think you could make an OS two orders of magnitude harder than current commonly used systems. It will never be complete mathematically provable security. Just make it so hard to do, that the cost increases enough to change the fundamental economics, so that only very high value targets will ever get that degree of attention. (Which means that the cost has to be much higher than someone's credit card number.)
Bernstein disagrees with you, in his analyis of 10 years of qmail security. Worth reading.
The problem with sandboxing is the misalignment of effort between attacker and defender. Sandboxing and capabilities are a huge pain in the ass for the defender, who have to construct and deploy applications with perfectly configured security controls. They're just an obstacle course for attackers.
qmail is a program written in C which runs on UNIX. Trying to secure that is a near impossible task.
Building a secure system would basically need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language. Even then drivers and HW would need to be treated with the utmost care.
Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible.
need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language
Didn't Microsoft already do this with Singularity?
Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible
I don't think it would be so horribly expensive. The Lisp machine software was written by a team of 8 or so. The effort for an OS is probably commensurate with BeOS. That's expensive, but not horribly so. Retarget a C compiler for your VM bytecodes, or better yet, just have everything run in an NaCl sandbox. Instead of bytecodes, have your virtual ISA be pseudo x86 or ARM instructions. Then port a lot of GNU code over.
How to make an OS virus-free? It's quite simple actually, make it so difficult and/or useless that it will have no user base whatsoever.
Windows has so many viruses because it's the most popular OS in the world (not the best imho, but that's for another flamewar). Mac OS used to be mostly virus-free until it started rapidly gaining in popularity. Linux as well, though the technical prowess of Linux users is generally MUCH higher so it may just be that potential Linux viruses don't spread as much.
This is a good point not mentioned yet. The number of viruses targeted to an OS is directly proportional to the market share it has. As long as it stays in single digits any "economically rational" virus maker will write yet another windows virus instead of working on an unfamiliar platform.
Whether it will be technically more difficult to write a virus on linux, max of chrome os, we will only know for sure when/if they become a target tempting enough.
The 'best' method to keep viruses off an OS is what Apple is doing with the iphone - reviewing every app by hand before it is allowed to run on the OS. Even that is far from foolproof though, and it has a whole host of other problems.
They aren't actually reviewing apps by hand, the reviewers aren't remotely competent enough to make any technical assessments at all. They don't even review obvious copyright / trademark infringement!
They don't do any basic static analysis of your object code, even to check for private symbols, and they don't have your source code. They don't even take the obvious step of having some APIs be mutually exclusive!
Their process is as immature as it could possibly be. I had assumed the reviewers were mouthbreathers from a temp agency, but apparently they are actual Apple employees! It's possible that they're just the low-skilled drones that were reviewing media submissions from the labels and studios.
I like the comment on Schneier's blog:
Similar to the old saying... secure, functional, easy-to-use.... pick any two...
-- Posted by: BillF at July 10, 2009 11:11 AM
An operating system cannot be virus free. Because of the human error. Even if we made the 100% perfect virus checker, the human part of the equation will always find a way to give out their password or admin privileges to a phishing site or many other scenarios.
That said, there are tools an OS can do to mitigate the damage that viruses can do. So while there will always be a smarter virus, there can always be a way to only let the smart virus get to something that it could have gotten to no matter what.
Its like Google Chrome. Google Chrome itself is not perfect, has MANY (those we know of, those we don't) security flaws, BUT getting out of the sandbox that Google Chrome provides is a very difficult problem. The basic idea is really to let viruses happen. Just let them get made. There will always be a security hole to exploit. As long as the damage the virus can do is very limited and moot it won't matter.
That might be what google is doing. Maybe they are just making a super-glorified browser-based system in which google chrome's sandbox protects the user while googles native client allows all sort of cool programs to run and in the end you are still on windows, but the security risk is absolutely minimal.
The only solution that will make an OS virus free is to not ever release or use the OS.
Indeed, even programming the OS itself could result in the introduction of viruses, so it's probably better to just leave it on the drawing board without ever actually implementing it.
Virus study is fringe computer science. When there are vast tracts of solid systems research across operating systems, compilers, and symbolic analysis to cite, reaching for the goofy fringe stuff is not a credibility enhancer.
I don't think Schneier has shown he has anything useful to say about Chrome OS yet.