Forcing access-based security with virtualization

The Internet Explorer security zones are useless. There aren’t any sites I trust enough to let do things to my computer without prompting. Nor are there predetermined sites that I’m afraid of. Those, I generally stumble onto rather than prepare a list of, in which case it’s already too late.

Surely the security zones can serve some purpose. How about this? Give the default zone the restricted permissions of the Restricted zone and give the Trusted zone the permissions of the default zone. Now the zones can be put to use. Instead of giving sites normal access by default and restricting them on a case-by-case basis, I distrust them all by default and selectively give normal access. My perversion later shipped with Windows 2003 under the name Enhanced Security Configuration (ESC) along with the ability to easily add sites to the Trusted zone. It’s a bit of an annoyance, but the security is worth the inconvenience.

How about applying this security paradigm to the entire operating system? Currently, Windows is set up like IE’s original security zones. Programs can mostly do whatever they want except for a list of restrictions. They can’t access each other’s memory (NT) or call certain APIs (XP SP2). Rather than being allowed to do respectable things, they’re banned from doing forbidden things. It’s not a difficult ban to evade in most cases. Denied access to a file? Access the raw bytes of the disk. Can’t call a banned API? Use assembly. It’s much like IE allowing web sites to execute JavaScript, but banning certain functions or methods. Clever exploits will always find ways around this. But what is the alternative? Much like sites that fail without JavaScript, old and poorly-written applications need machine access to function at all.

The current strategy is failing. More restrictions are added by the OS while an arms race occurs between viruses and antivirus software. Anti-spyware applications play on the same field as the programs they try to eliminate, watching for ShellExecute hooks by making the same type of hooks and watching for malicious startup applications by trying to place themselves before those applications in the same list. Restrictions simply breed more creative workarounds and we know that arms races cannot be “won” at all.

There is a complete solution. Dot NET with its high-level API, common namespace, and sandboxing are the opt-in part of this solution. They’re analogous to the sites that get added to the Trusted zone and are allowed to do normal things in ESC. What about the malicious or poorly-written programs left in the Restricted zone that would’ve normally been allowed to execute? They are virtualized.

(Virtualization is like The Matrix. If you imagine your computer to be the real world, then a virtual machine is a Matrix inside that real world. Programs running in this Matrix think they have full access to a real computer and manipulate files and memory in it, but are unable to harm or even determine there is a “realer” computer.)

Virtualization is the second part of this security solution. If you’re an old program or you don’t want to play by the rules, your execution isn’t thwarted by a watchful kernel or DEP. You can fully execute…on a phony machine. No real disk access. No painting regions of the real video memory. No executing assembly that modifies the registry or fetches spyware from the Internet. It is a performance hit, but not much of one since it’s all x86 code. Perhaps there is one virtual machine for all untrusted applications or maybe one stripped-down machine for each untrusted application. Regardless, in the very worst imaginable case, a virtual machine can only destroy itself.

As the virtual machines are improved, they’ll more tightly integrate with the real machine. Each will use whatever it wants to manipulate what it thinks is a real registry, file system, network, video memory, etc. The real machine will go in and extract keys, files, and memory regions to allowed locations in the real machine. In reality, the virtual machine’s entire file system is just a single file on the real machine’s hard disk. Virtual machines will have functionality that is only deliberately and carefully added to the real machine and nothing more. Since it takes a concerted effort to go into a virtual file system and remove files from its phony My Documents directory, there is little risk of security breach. When security is a result of adding functionality rather than removing it, it is always much more robust.

This post is licensed under CC BY-NC-ND 4.0 by the author.