Is dual-booting an OS more or less secure than running a virtual machine?

Question

I run two operating systems on two separate disk partitions on the same physical machine (a modern MacBook Pro). In order to isolate them from each other, I've taken the following steps:

1. Configured /etc/fstab with ro,noauto (read-only, no auto-mount)

2. Fully encrypted each partition with a separate encryption key (committed to memory)

Let's assume that a virus infects my first partition unbeknownst to me. I log out of the first partition (which encrypts the volume), and then turn off the machine to clear the RAM. I then un-encrypt and boot into the second partition. Can I be reasonably confident that the virus has not / cannot infect both partitions, or am I playing with fire here? I realize that MBPs don't ship with a TPM, so a boot-loader infection going unnoticed is still a theoretical possibility. However, this risk seems about equal to the risk of the VMWare/VirtualBox Hypervisor being exploited when running a guest OS, especially since the MBP line uses UEFI instead of BIOS.

This leads to my question: is the dual-partitioning approach outlined above more or less secure than using a Virtual Machine for isolation of services? Would that change if my computer had a TPM installed?

Background:

Note that I am of course taking all the usual additional precautions, such as checking for OS software updates daily, not logging in as an Admin user unless absolutely necessary, running real-time antivirus programs on both partitions, running a host-based firewall, monitoring outgoing network connections, etc. My question is really a public check to see if I'm overlooking anything here and try to figure out if my dual-boot scheme actually is more secure than the Virtual Machine route. Most importantly, I'm just looking to learn more about security issues.

EDIT #1:

As pointed out in the comments, the scenario is a bit on the paranoid side for my particular use-case. But think about people who may be in corporate or government settings and are considering using a Virtual Machine to run services or applications that are considered "high risk". Are they better off using a VM or a dual-boot scenario as I outlined? An answer that effectively weighs any pros/cons to that trade-off is what I'm really looking for in an answer to this post.

EDIT #2:

This question was partially fueled by debate about whether a Virtual Machine actually protects a host OS at all. Personally, I think it does, but consider this quote from Theo de Raadt on the OpenBSD mailing list:

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

-http://kerneltrap.org/OpenBSD/Virtualization_Security

By quoting Theo's argument, I'm not endorsing it. I'm simply pointing out that there are multiple perspectives here, so I'm trying to find out more about the issue.

Answer 1

Answer first, then why: A virtual machine can be more secure.

From a practical standpoint, there exists code and malware that can infect both boot partitions, BIOS, and also hardware devices. So, a VM has slightly more advantages in a reduced attack surface from a generic point of view - potential VM hopping code is the largest one specific to the VM. This code is likely to be specific to the type of VM being employed such as the recent http://www.kb.cert.org/vuls/id/649219 issue. Note it required a specific virtual machine (kvm or xen), ring, etc.

So, from the perspective of hostile code, virtualized is more secure.

Approaching from the network angle, many users of virtualization solutions have more flexibility at the network level via NAT within NAT, PAT, or other features an OS may not native support, or rolling their own enhanced security through use of the VMs. It is fairly trivial to enhance a secure posture via using a specific VM to inspect all traffic i/o with virtualization.

So, from the perspective of network security, virtualized is more secure.

Onto guest operations. The beauty of cloning operating systems in second...Depending on the type of virtualization solution being employed, a powered off VM can be patched transparently without action by the user. It is trivial to take a general purpose VM, and lock it down using various hardening guides to where there is minimal functionality except from specific applications. VMs make it easier to perform extreme levels of hardening such as performing least privilege on certificate trust stores (e.g. I delete most certificates from commercial CAs except for ones I am using) These type of activities can be much faster with a VM due to the ability to snapshot and recover from catastrophic changes. Furthermore, a VM in entirety can easily be packaged up into a file and saved somewhere, on a USB, etc. Also, when you think of compromises, realize that in virtualization, a compromise can be much less privileged than regularly. In a type 1 hypervisor for example, it is the hypervisor itself that is the most privileged instance on the computer.. Increasing levels of hoops for an attacker. It can also be used to grant developers administrative/root access, without granting said developer domain admins, or privileges on the corporate LDAP.

So, from the perspective of guest operations, virtualized is more secure.

However, I'm going to focus on the premise for a second - that virtualized and booted up native type OSes are either-or choices. They aren't, as you can boot a virtualized OS using 3rd party solutions as if it was a dual boot option. Software like vboot enables VHD/VMDK/VDI/Raw format booting.

As far as types of virtualization go, there are a few that are applicable to this case. Those being Type 1 virtualization (bare metal), Type 2 virtualization (Hosted OS) and I consider partial, operating system & paravirtualization out of scope. The leading x86 type 1 virtualization solution, VMware vsphere hypervisor, uses a microkernel approach with a minimal attack surface. Type 2 virtualization have bigger attack surfaces since they rely on a full underlying operating system. So, Theo's comments about full operating systems is incorrect when applied to VMware.

Here is some VMware propaganda on the topic

http://www.vmware.com/technical-resources/security/overview.html

Of course, security is most often a tradeoff between usability and security. It is important to consider a threat situation that a user is likely to encounter, and who will deploy resources against you to attack you. If you are a nation-state or bank you need extensive protections. Companies, more. Individual users of little notoriety - good enough protections. Keep in mind that a good security solution protects you enough, but does not negatively impact usability to the extent of being a hindrance. Overall risk management is a different topic, worthy of review elsewhere.

I didn't talk about more exotic security approaches, such as thin clients that could be used to expand upon virtualization security by further reducing attack surfaces, or TPM lockdown in conjunction with a type 1 hypervisor.

Answer 2

Each is more secure in it's on regard.

If you want to build a "sandbox" environment where you can experiment with dangerous code, then doing so within a virtual machine is more secure than with a dual-boot environment. This appears from your question to be what you're asking for. The reason why is because a virtual machine does not have direct access to your hardware, it runs as a program emulated within a program such that the entire runtime environment only exists to the extent that the virtualization system allows (assuming no security bugs in your hypervisor). If your VM system declares that hard drive access is impossible, then the program running inside can't access the hard drive.

If, on the other hand, you want to "escape" your standard environment and create a known-secure environment, then dual-booting is the only way to get there. The reason is that because a VM exists as a program within your standard desktop, then any security failings in your standard desktop can also extend to the VM itself -- the desktop can intercept trafffic, keystrokes, disk access, etc., done by the VM. So if your desktop is not secure, then your VM cannot be seure. This appears to not be what you needed, but it may be useful to understand for future use.

Answer 3

Personally this sounds like it's bordering on paranoia for people who aren't doing research on malware.

If you're running 2 different OS's, you'd need malware that knows how to read the two difference filesystems.

If it's running in a VM, you would need the malware to be specifically targeting the hypervisor so it can break out of the sandbox.

You're already mitigating some of the obvious ways for something to infect you by running with lower privileges and such. Otherwise, your best mitigation tasks would be regular backups, scanning for malware, or for me, when running a system that is UNIX based you can run file checkers that use checksums to monitor file changes then email you when suspicious files/changes are found.

Also with a VM you can create a share folder in which to save permanent data, then just take a snapshot of your VM, do the coursework, then roll back the snapshot so anything that could have happened to your VM would be erased. Malware would need to specifically know about your share in order to copy itself to a share, and even then it can't run.

While security must be layered to be effective, it doesn't take much to do some basic care for your average use. Personally if you're afraid of some activity in particular causing problems, I'd just snapshot and roll back during that work. Using different OS's and file checksum monitoring should tell you if anything has happened then restoring from backups would probably be more than enough, as anything to break the VM and affect different OS's would have to be very targeted just for you.

Answer 4

There are some theoretical risks (which have not been proven yet) that would make the dual-boot approach less secure. These involve offloading a trojan onto a non-standard piece of hardware. For instance, infecting the battery's firmware with something that will then overflow the kernel's power manager. That could cross reboot boundaries and you don't really have any say over it. The VM approach would not suffer from this weakness.

To the best of my knowledge these are at proof-of-concept at best, but then again, that's in the whitehat world. I would not be surprised if the NSA has this working.