5

I am exploring using VMs to separate my administrative actions from standard user actions in Windows 7. The goal is to limit my risk and exposure when using "RunAs" to open an application or file share and separate that from any other application or file that may be on my machine.

What is the technical process to get Windows 7 into this configuration?

It seems to me that if I can load my administrative tools onto one VM, my Office and development applications into a second VM, then I can boot into either as needed. If I need temporary access to one environment from the other, I can simply boot up the corresponding VM and multitask all while knowing that my environments are separated.

I want to prevent the "transitive trust" that forms when I RunAs to access a file share for example, and then a malicious website infects that drive.

makerofthings7
  • 50,488
  • 54
  • 253
  • 542
  • 1
    I'm not sure why you wouldn't just do this using the existing built in process of using separate accounts - an admin, and a user account. If you need to run a particular command as admin while user, you can do that. – Rory Alsop Sep 29 '11 at 21:17
  • I think of it as a shortcut to `run as`. I work on the IT Service Desk (helpdesk) , IT Engineering (Viso/Office), and App Development (Visual Studio, notepad). Those 3 worlds need isolation,and have distinct applications associated with each. Also it would be devastating if I make a mistake in "dev" while using admin credentials. – makerofthings7 Sep 29 '11 at 21:21

1 Answers1

5

I am also not entirely sure I understand - so let me offer some possible solutions:

  1. Use three separate virtual machines as described here by a rather famous security researcher. Essentially - each virtual machine is a totally separate environment, ideally speaking as if you had three separate computers. In order to effect this, you'll need a virtualisation solution of some form (virtualbox, vmware etc).
  2. Use different accounts and don't use RunAs. You risk data leakage this way but it's a lot easier than spinning up the required virtual machine.
  3. Use RunAs and accept the risk.
  4. Do not use RunAs.

I should briefly talk about those virtualisation features. Those features are provided to enable XP-mode to work through Microsoft's VirtualPC.

Clearly, do not use RunAs is not acceptable and using three VMs might be a bit painful, as is constantly logging out as in 2. There might be a way you can make this work for three:

In terms of current administrator accounts, what actually happens is that your ability to act as an administrator is curtailed by privilege levels. Three components come into play - UIPI, Mandatory Integrity Control and separate desktops via CreateDesktop. How they interact is complicated:

  1. MIC says each process is either High, Medium or Low Security. I think it also includes a DRM level - and I know it also includes a System level. In either case, the idea is that a Medium object cannot meddle with a High object. See here and here. Likewise a High object cannot read a medium object - this is no write up/no read down in action.
  2. UIPI says that only certain messages can be sent from Low to Medium and Medium to High processes. The whole GUI model resolves around sending messages; if hardware generates a event, that's a message in your message processing routine (usually called WndProc).
  3. CreateDesktop creates a whole new blank desktop. Sysinternal's rootkitrevealer does this, as does KeePass, as does consent.exe, your UAC dialog process.

What makes consent.exe secure is the combination - not only is the process run as NT AUTHORITY\SYSTEM (which ordinarily would not be a barrier to an Administrator user) but it also runs on a separate desktop (it takes a screenshot of the current desktop and grays it out to achieve that effect I believe) and it runs as a HIGH privilege level, meaning not only can medium/other processes not get to it if run as an Administrator, but the desktop is unique and there's nothing else on it to send messages to it.

So, you could use the mandatory integrity controls to isolate some of your processes. One drawback is that you can't easily use the CreateDesktop mechanism yourself - it's a programming instruction. You can however combine MIC with separate accounts on a single desktop. You might like to read some thoughts on that by the previously-mentioned famous security researcher. With a bit of experimentation you might be able to adapt this to your needs.