The Effects of Dual-boot or Multi-OS Systems on the Security of the 
Network and the Sanity of the Admin.

by Zube

original:  Apr 28, 2000
updated:   Feb 1, 2008

Q: Why are you so opposed to multi-OS computer installations?

A: I'm not opposed to multi-OS configurations ("dual-boot" from now on).  
Such setups can be very useful.  What I am opposed to are dual-boot 
computers that are directly connected to the math network.

The most important aspect of my job is security and the most important
facet of that is knowledge.  For the math network to remain secure,
I must know what computers are on the network and what they are running.
This allows me to act quickly when security holes are discovered and also
to plan patches and maintenance in a sensible manner. 

Dual-boot systems turn order in chaos.  

Suppose a linux security hole is discovered.  I attempt to fix this
hole on a particular machine, but it's currently running Windows and
the owner is running something that shouldn't be disturbed for a while.
This security hole is now a potential time bomb.  Only when linux is
booted will the machine (and the network) be at risk; given the whirlwind
busyness of life, will the owner of the machine remember to tell me when
it's in linux?  Will I remember that the machine has a security hole?
Is it worth putting the entire network at risk for the convenience of
one user?

From a security perspective, it is much easier to deal with one 
always-available quantity than two partially-available ones.

Another problem with dual-boot machines is time.  It takes a significant
time investment to properly configure, secure, and periodically re-secure
a machine.  Dual-boot systems by their nature double the time required
for this to occur and also more than double the maintenance time.
In addition, in my limited experience, most people who have dual-boot
machines use one OS approximately 99.7% of the time.  Thus, the extra
time and effort put forth to configure and secure the machine (which
absolutely, positively needs to be done if the machine is to be connected
to the network) is mostly wasted.

In the past, faculty have asked Math system admins such as myself
what could be done to help lighten our ever-increasing work load.
The reply was usually "nothing," because much of what system admins do
is inherent to the job.  If asked today, I would now reply, "Don't run
dual-boot systems."

Dual-boot machines introduce other problems.  Suppose the Windows
side of the machine contracts a virus.  The virus, if malicious, could
potentially wipe out not only the PC side, but the unix side as well.
A rebuild of such a system is then, again, 2x the work and > 2x the
maintenance.

Another problem area is backups.  Backing up both the unix and PC sides 
is 2x the work.

Then there are the subtle issues.  For example, OS #1 and OS #2 both
sucessfully use the built-in wireless card.  A security problem arises
in the wireless drivers in OS #1, requring a driver update.  That update
silently installs a firmware upgrade to the wireless card.  Result:
wireless network is secure and works fine in OS #1, but wireless network
no longer works in OS #2. 

In contrast, I am much more amenable to maintaining two separate computers.
Yes, this is still 2x the work of a single computer, but it is still more
manageable than a dual-boot computer and such a setup doesn't suffer from 
many of the problems listed above.

From a security perspective, it is easier to deal with two always-available 
quantities than two partially-available ones.

Therefore I ask that all machines directly connected to the math network be 
single OS machines.  Such a policy improves the security of the network,
adds a few hours to my sanity's already short lifespan and reduces my overall 
workload.

That being said, I can think of some instances where I would compromise
on dual-boot systems.  For example, if a laptop were configured as a
dual-boot system but only one OS was used exclusively while connected
to the network *and* I had no responsibility for the configuration,
maintenance or backup or sharing of files with the other OS *and* it,
by default, booted into the chosen OS, I could probably live with that.
In this case, I'm still only managing one OS per machine and since the
other OS is never used on the math network, I have no security or time
concerns regarding it.  In practice, however, such compromises almost
never stick ("really, I just need to print from windows!"), which is
why I almost always say no.