|
Virtualization as an Antivirus
A friend recently asked for my Windows antivirus utility recommendation. I gave him an answer he wasn’t expecting: VirtualPC.
I run VirtualPC on my PC, running Windows XP under Windows XP. I have a bunch of machine images, but they all fall under one of two categories: application and disposable.
The application images are virgin XP installations with the addition of one application. I never install more than one application per image for damage control reasons (and never allow them to run concurrently). These application images are never allowed to play on the Net. They don’t use the Web, they don’t get email, they don’t even a use network volumes.
Only the disposable images are allowed to play on the Net. Even if/when they get compromised, they don’t last long — I shutdown the image and use Undo Disks to throw away whatever changes they’ve made. Thus pretty much every time I use IE6, I’m using it from a “fresh”, untainted XP install, regardless of what malware snuck in the last session.
There is a glaring flaw in that the virtual XP can see the host’s real XP. Conceivably, I could visit a site in a disposable image, which infects the image and spreads to my real XP. The infection then could further spread to each application image as it’s launched. This hasn’t happened yet, mostly because I’m careful about which sites I visit even when using a disposable image.
One solution is to fully migrate from VirtualPC/XP to Parallels Workstation/Mac OS X. That way, an infected disposable image wouldn’t be able to find another Windows box behind my firewall, and thus would be guaranteed to die upon image shutdown.
I should mention this virtualization-as-an-antivirus only works for me because Windows is not my primary platform. If I had to use Windows to perform common tasks like reading email or viewing lots of arbitrary websites (typical surfing), I would definitely invest in traditional Windows antivirus software.
Update: Christopher Ashworth writes:
I haven’t written you before, so you don’t know who I am, but I’ve been reading your notes and articles for a little while now. As for me, my day job is working at a computer security company, and my nights and weekends are occupied with XCode.
I thought I’d drop a note your way to offer a bit more context on your recent “Virtualization as an Antivirus” article. Forgive me if you already know this stuff — I just think it’s pretty interesting and that you would find it so too, if you didn’t already know it.
The security mechanism you describe in your article is a form of Mandatory Access Control (MAC). You are effectively defining domains within which your applications must run, and they only have access to the resources in those domains. Even a root user in a Unix VM can’t get access to the application you run in a separate VM. This mechanism strongly contains any accidental or malign activity within the domain of operation in a mandatory way (as opposed to a discretionary way, e.g. Unix file permissions). As such—and as you imply but don’t quite say explicitly in your article—virtualization kicks the ever-loving pants off of traditional antivirus software, vis-a-vis protecting your computer from viruses. You don’t even have to know what the virus looks like, what it does, or how it works. You don’t need to know anything about the virus at all. Your architecture confines any virus, past present & future, by design. Each application in each VM gets access to only the minimal set of resources it needs, and thus you know for a fact that if it is corrupted the damage can only get so far. This is, as we like to say at work, the power and the glory of MAC.
The virus software, in contrast, is doomed to painful and repeated failure because it can only catch what it already knows.
The trick, as you note, comes in when you need something a little less totalitarian than complete resource separation. In many circumstances, you can’t really get your work done unless your applications can share resources a bit. This is where it becomes necessary to have true MAC support in your operating system. Using such a system, it becomes possible to define in formal, granular, analyzable terms exactly what resources programs are allowed to use across the entire system. Each program still gets access to a minimal set of resources, but those resources might cross boundaries a little bit if it is necessary. You might enforce one- way information flow between certain application domains, or wall off your password file from everybody but the password program, or implement a Multi-Level-Security architecture so your unclassified agent can’t ever (no matter what!) read any of the top secret agent’s documents, even though they use the same machine. It’s pretty cool stuff.
I knew about SELinux and the security advantages of virtualization, but I didn’t put together their correlation to Mandatory Access Control. Thanks, Christopher!
Update: Peter da Silva writes:
I wouldn’t describe VMs the way you’re using them as an implementation of mandatory access control, because they’re not. You’re still using discretionary access control… in a MAC system, you wouldn’t be able to transfer information from the environment with a higher classification to the environment with a lower classification even from the environment with the higher classification.
Obviously, that’s not what you’ve got. So you’re not employing MAC.
What you’re using is an extreme version of the principle of least privilege. You’re creating an environment that doesn’t have the privilege of writing to any local non-volatile storage.
Virtual machines are overkill for that, but on Windows that’s about what you have to do… because the browser doesn’t apply the principle of least privilege to the documents you view in it, and the OS doesn’t apply the principle to the user… since you have to effectively have administration rights to do anything.
UNIX (and hence Mac OS X) does a lot better job of this, because it provides and by default uses a variety of tools to limit privilege.
Privileges can be assigned to groups through gateway programs and file permissions. So you can have a modem owned by group “dialer” and grant access to the modem to users in the dialer group just by putting them there. Similarly, you can give your print spooler access to a printer port and spool directory through group permission, and then make the spooler setgid to that group, so that users don’t have to be able to write to the spool directory or printer port to print.
Windows has a lot of privileges that can be assigned to groups, but because it doesn’t have a gateway program mechanism users end up having to have all the privileges in the world anyway. Historically, UNIX systems have run “locked down”, so applications don’t assume they can write back to their configuration files and things like traverse checking in the file system can be enabled by default. UNIX’s use of a single namespace for access to resources allows you to more easily understand and enumerate the rights a process has, and you can use chroot to create a more limited environment without the overhead of VMs. In FreeBSD (but not, unfortunately, carried over to OS X) you have jails that provide almost all the security of a VM with little more overhead than a process.
But Windows… yeh, VM is probably the best you can do. Icky as that is.
Update: Christopher responds to Peter and moves the conversation off my blog.
Saturday, April 29, 2006
12:00 AM
|
