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?


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.


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.

migrated from superuser.com Jun 28 '12 at 21:03

This question came from our site for computer enthusiasts and power users.

  • Can you just limit connections to the course website? In that case, it's at least less likely that you'll encounter any exploits. Unless you are afraid that the school web server is going to be compromised. The risk of infection in the first place should be quite low if you are running AV and limit the VM's use to the school web site--therefore the risk of cross-infection is irrelevant. – Quinten Jun 27 '12 at 21:32
  • I have zero confidence in the school's IT department to secure their systems. The instructor's are great, but nearly everything about the online portal makes me question the school's systems. Great thought though! – Mark Hammonds Jun 27 '12 at 21:34
  • 1
    A VM is generally more secure for numerous reasons, but don’t forget that there are plenty of routes in and out of a VM (NICs, shared folders, I/O devices, etc.), so to truly protect it, you would need to lock them all down. Also, while in theory, a piece of software in a VM is supposed to be oblivious to the outside world, they are not truly segregate (e.g., VMWares Tools, Red Pill/Blue Pill, etc.) – Synetech Jun 28 '12 at 3:05

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


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.

  • Wow, thanks for this! I'm still digesting everything, but your points about vulnerabilities in attached hardware devices and network isolation of the VM are really great. In my mind, you've definitely made a convincing case for a VM being the more secure approach. I will likely accept this post as the answer, but I'll give it a bit of time in case someone has counter-points against the virtualization approach. – Mark Hammonds Jun 27 '12 at 22:21
  • 1
    Do you have any feedback on the perspective of Theo quoted above, with regard to virtualization on x86 simply introducing "another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection"? The implication is that using a product like VMWare to run multiple services on one server places all of those services and the host OS at risk. I'm not sure how seriously to take this assertion. – Mark Jun 28 '12 at 0:19

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.

  • I appreciate the feedback, and I agree with you that having a second partition can be useful for "escaping" to a "fresh" environment. Of course, a virus can theoretically spread between partitions, but the probability of that seems low and can be mitigated by external monitors and AV scanners. – Mark Jul 3 '12 at 21:58
  • 2
    @Mark Better still: live CD boot – tylerl Jul 3 '12 at 22:00

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.

  • Thanks for the feedback. Both OS' are the same (OS X Lion). My main objective here is just to learn more about IT Security, specifically any trade-offs involved in the above scenario that I may not be aware of as I still consider myself a student. – Mark Hammonds Jun 27 '12 at 21:39
  • In theory there are ways to break your system three ways to tuesday in the hands of a knowledgeable system hacker. Even with your system encrypted but asleep you can get the system cracked through DMI access in the firewire port, as I recall. Practically speaking, that's a different matter. Look at something like Stealth for having two systems work as a team to keep a system safe. Take good backups. With VM hypervisors, snapshot and roll back. – Bart Silverstrim Jun 27 '12 at 21:42
  • The number of malware out there hitting Lion is relatively small. Very small. And no antivirus is all-encompassing, and some can actually cause problems at times. That said, the vast majority of hacks on systems are automated or scripted, not specifically targeting such a roundabout set of attack vectors. – Bart Silverstrim Jun 27 '12 at 21:44
  • No, I'm not saying Lion is immune, but relatively (and practically) speaking it is not a major target. The only way to completely secure it is to encompass it into concrete with the Airport shut off. In Practical terms, you sound like you're going overboard. Keep good backups and monitor your system for changes and you should be fine. Actually, if you wanted to take it to some extreme you could run a VM with Linux whose sole purpose is to run stealth on your Macbook using SSH keys and cronjob. Anything changes you don't know about it can email you. But VM's will eat resources... – Bart Silverstrim Jun 27 '12 at 21:47
  • Oh, and for a MacBook Pro, it's a good idea to encrypt and password everything to guard against thieves getting access to your data. Be a shame to do a ton of work to "secure" the OS's only to have someone walk off with it, and encrypt your Time Machine backup drive. – Bart Silverstrim Jun 27 '12 at 21:48

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.