Google Oompa-Loompas dream of virus-free OS
Everlasting gobstopper
Agentless Backup is Not a Myth
Google has rather rashly claimed its plans to develop an operating system promise an end to security woes.
The search giant said Google Chrome OS, due to debut in the second half of next year and initially targeted at netbooks, will be based on open source code and offer unprecedented security.
Sundar Pichai, VP of product management and Linus Upson, engineering director at Google, pledged an end to not just the need to run antivirus but of security updates more generally in a blog posting. The duo go on to boast that Google's sugar-coated OS will also offer speed, simplicity, an end to world hunger and an England Ashes win (we made the last two up).
Speed, simplicity and security are the key aspects of Google Chrome OS. We're designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web. And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates. It should just work.
Carl Leonard, security research manager at Websense, describes Google's goals as commendable but essentially unachievable. He cited flaws in the Chrome browser as example of the kind of issue that were likely to effect Google as much as any other software developer.
"All software is susceptible to issues – it just depends on how much effort the malware author wants to go to and how much profit can be made," Leonard said. "Already we have seen vulnerabilities and issues with the Chrome browser, and Google even ran a contest in which two well-known security researchers found 12 exploitable security flaws in the company's Native Client system."
"Two of the top three security threats (SQL injection, browser vulnerability and rogue av) rely on software flaws so we know that it’s likely that malware authors will be looking for flaws in the Chrome OS to take advantage of from day one," he added.
Google Chrome OS, designed to run on both x86 as well as ARM chips, will run "within a new windowing system on top of a Linux kernel", Google explains. The project to develop a web-based OS for networks is separate from Android, Google's OS for mobile phones and devices such as set-top boxes.
Extended betas of Google's web apps, such as Gmail, incorporate technology to track user experience so its not that much of a stretch to imagine something similar might be incorporated into its Chrome OS, a factor that would have obvious privacy implications.
Graham Cluley, senior technology consultant at Sophos, said details published thus far suggest that apps would run inside a browser rather than getting installed. Such an approach might mix up the malware problem without eliminating it entirely.
"A lot of existing malware won't work but that still leaves potential problems from issues such as cross site scripting worms," Cluley told El Reg. "Storing data in the cloud also poses privacy concerns," he added.
Cluley described Google's security boasts as "marketing blurb" that ought not to to taken too seriously and certainly no reflection on the security expertise the search engine giant is able to call upon. ®
COMMENTS
PR nonsense
What a load of PR nonsense. I'm a Google fan - but this smells of massive arrogance.
@ Daniel 1
Actually, I think the Chrome logo looks very much like the old Simon electronic game from the '80s.
http://en.wikipedia.org/wiki/Simon_(game)
Humour Me. Please....
Here follows some thoughts of mine as to how Google's OS could pan out. Comments, discussion, ridicule and hole-poking (ahem) at the ready...
The general consensus seems to be that the only way in which Google have any chance of producing a "virus free" computing platform is to severely limit the user's capabilities and sandbox absolutely everything. Many people seem to think that this is too difficult, or that the users won't like the restrictions.
I'll address the second point first. Users won't care so long as they can still surf the Web, check their e-mails, and update their status on whatever social networking site is the current flavour of the month. Additionally, users will happily accept some restrictions if the overall experience is sufficiently good (cf. the iPhone).
Now to address the first point. Almost all operating systems limit what a user can do based on user-level privileges. And any software they runs has the same priviliges. However, these privileges only cover what files etc. the user/app may read/write/execute. My arguement is that this is not enough, and a more prohibitive model can be made to work.
For example, a user is limited in what apps they can run (e.g. via code signing from Google). Malicious apps, such as viruses, won't be signed and thus won't run.* The OS could also verify app signatures at boot/launch.
*if a signed app were found out to be malicious, its certificate could be revoked.
I also expect the user to have no admin rights. That is, they cannot modify system files, and can only install apps in userland. OS updates will be handled automatically in the background by Google (OK, so their update code had better be tighter than a gnat's chuff). In fact, the only process which can modify system files is this update code, and that too will be stored in OS-land.
Now, as regards running native code etc (e.g. via V8), every process would be sandboxed and child processes only permitted to communicate with their parent.
To cater for the possibiltiy that malicious apps were able to run, and then modify userland files, apps could be forced to use a common API for disk read/writes. Files created (and owned) by the app (e.g. preference files) could be read/written without interference, but user files would require opening/saving via a common dialog system. That is, the app tells the OS it wants to open a file and the OS then presents the user with the file open dialog. Same goes for saving. So, apps become like first-class citizens with respect to file permissions.
Does any of this sound reasonable? Am I mad? Could this work?
P.S. I don't want to sound like I believe this will prevent viruses/trojans/etc. but I do think it could put a big dent in their pervasiveness.
Paris for the "hole-poking" bit at the start, and for the potential cluelessness of this post....
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
