I was wondering about the security implications of running a GUI in a VM. I know that a GUI adversely affects security, but don't know how this works when visualization is thrown into the mix.

My two main questions are:
1. Is the security of the host OS affected by the presence of a guest OS with a GUI, or is it just the guest OS that would take the hit?
2. If the host OS does not have a GUI, and the guest OS does have a GUI, would it be possible to see the GUI of the guest OS?

My two main questions are:
2. If the host OS does not have a GUI, and the guest OS does have a GUI, would it be possible to see the GUI of the guest OS?

since your asking about a command line vm, i'm going to take it that your server doesn't have a gui on it now, and you're running esx.
NO.
the way that you will be using your vm's is on a web page. since the host doesn't have an X environment running, your guest won't be able to start anything up.

1. Is the security of the host OS affected by the presence of a guest OS with a GUI, or is it just the guest OS that would take the hit?

just the guest. vmware basically runs in a chrooted environment.

Not that I'm a super hardcore security expert, but I believe this to be patently false information.

#1 - if the VM software can run in a terminal (without X) has no bearing on whether or not the hosted OS can run a UI (see vnc under unix for examples). Not to mention that your X display can be hosted on a different machine and run X across a network.

#2 - Just as chroot jails can be broken (google it), there are valid attacks against VMWare which break out of the VMWare "hypervisor" or whatever it's called. I'll try to find a link to a good example and edit it in. Especially with the amount of hype that cloud computing and virtualization are generating, the next big wave of corporate attacks will likely be against this type of target.

Okay, thanks for the responses. I actually don't have anything installed yet, but I plan on using Debian with Xen, CLI only, as the OS installed on my server. I will then have a few guest OS/VMs that run within that, which will also be CLI only.

Then I got to thinking "Maybe I could install a GUI VM, too, just so I can have an extra desktop system available." At the same time, I didn't want to adversely affect the host installation by doing that.

Any thought on this?

Thanks again for the info thus far; I'm going to start getting the base install done.

orgcandman

you should really read the question and the answers poised. not just try and disclaim.

2. If the host OS does not have a GUI, and the guest OS does have a GUI, would it be possible to see the GUI of the guest OS?

what does that say?
you will not be able to see the guest os on the box that it's running. IT WON'T BE ABLE TO SPAWN AN X SESSION. if can't understand that, it means that X is not installed on the host system. the host system can not run something that it doesn't have. there fore it's a web interface that you will be looking at.

second,
please post the link that you're talking about. then i could read it also, and then maybe give someone the correct answer and learn how to set up my system to help prevent those kind of attacks.

Please, we're here to help, not degrade. if you would like to do that, then you should tell everyone that you're running windows and are just trying to pass FUD around.

take care

In the Unix/Linux world, it is perfectly routine to be running a GUI session against a rack-mounted box (somewhere on the planet) that does not have a graphics-card installed. Look on the back of that rack-mount unit and you will not even find a video connector. But you can still carry on a complete GUI session with it.

The reason why you can do so is this: the XWindows and XOrg systems are client-server. On a typical desktop unit, both components are running on the same machine at the same time but this does not have to be so.

Although the terminology is a bit topsy-turvy in this particular situation, the concept is the same: one component tells the other component what to draw. Other messages describe keystrokes and mouse movements. Your machine obviously must have graphics hardware, but the target machine does not.

I'd recommend the same for you. Please reread my post.

This quote tells me you haven't done enough research into X to understand it. Please RTFM.

http://www.immunityinc.com/documenta...rst-vista.html
This is the VMWare exploit. Very first google result, too.

If you're trying to state that I don't run linux and am making things up, that's fine - but I'll tell you you're wrong =D. At the end of the day, I know how exporting an X display across a network works, and am not close minded enough to believe that any technology is free from exploitation.

It all really depends on what your attack surface will end up looking like.

For instance - if the only way into this cloud (network-wise) is ssh, then you're more secure than if you open up ports for X and vnc, etc. At the end of the day, if its directly connected to the internet, I wouldn't expose more ports than the absolute minimum required which is probably just ssh. You can tunnel X11 through ssh, so if you setup your permissions (network) correctly, you should be able to get away with some basic UI components. My question would be - what UI components have no cli equivalent and do you think you need? I'd be hardpressed to come up with any.

For the second part, true. It would be purely convenience. I don't really "need" to, but if I can, and it won't affect the security of the other VMs and/or host/base installation, then I would like to. (Basically, if the GUI VM gets destroyed, that's okay, as long as the rest of the machine is safe.)

I am behind firewall/NAT devices; I would be forwarding ports as necessary. The GUI VM does not need to be available from the Internet, but some of the other VMs would be (Web/FTP/Mail/et cetera). Just as a note, some of the other VMs may be combined (like Web and FTP running on the same VM), but the GUI VM would not be hosting any "needed" services.

I put "needed" in quotes because this is not a business-oriented server; it is my personal server. I am setting it up for the learning experience, although I want to simulate (to a certain extent) what I would do if it were a business server. (If it were a business-related server, or if I were simulating to a greater extent, I would not be running the GUI VM at all.)

In this case, I would say that as long as you take proper precautions such as being careful on which ports are forwarded and which services are running... always keeping up to date on security patches... doing a daily or weekly review of logs... and running proactive security against your host, it should be fine. In this case, for your "gui" vm, I wouldn't ever run a native X server, but instead ssh from another workstation where you already have X running, and then just manually run those ui components you want (ie: run a remote, say, firefox session). It should be safer than running the native X (albeit a tad bit slower depending on the link) and gives you what you're looking for (I think).

Just to clarify some things up. The host server that runs the hypervisor "should" not be affected by the guest OS. However, if you have an expliot like the BluePill http://en.wikipedia.org/wiki/Blue_Pill_(malware) it does not matter if a GUI is running or not. The GUI is a security vuln. from a guest OS but not the Host OS. The GUI never talks to the host os it talks to the guest OS's kernel which in turn talks to the host OS. There is much more important things to worry about from a host OS perspective. Install what you want on the guest OS's then look at securing the guest OS. Don't worry about trying to cover the path of guest>host attacks. Rather secure the host OS and then secure the Guest OS's. If both of those steps are taken then you are mitigating the guest>host path.

Blue Pill is not that kind of exploit. It's a virtualization-based rootkit.

You would need to have gained root privileges on the host/native OS before you could use Blue Pill.

I read everyone's posts and I think this comes the closest to what I'm looking for:
Ah, okay. So sort of the same way a thin client works? (I can't think of a closer example I'm familiar with... but I know this isn't very close, either.)

Here's kind of how I'm picturing what you said:
Instead of "click here to open VNC client, then select the destination, then click here to connect, and then the desktop appears in the VNC window"...
...it would be more like "ssh into this box, run "startx", and there you go".

Is this accurate?

Something like that. It's really more like - "ssh into this box, forwarding x11, and run xterm". For an example commandline:
within an xterm:
ssh -fX myhost xterm

will pop up a window displaying an Xterm where the xterm is running on 'myhost' but rendered on the local host.

For running a full blown X service, you might have a look at enabling XDM and the XDMCP on the machine (but note - this is a huge security trip to frown town). In that case, you can actually connect to a running X server.

Also, VNC under unix systems spawns it's own X process (an example vnc commandline:
Xvnc :1 -desktop X -httpd /usr/share/vnc/classes -auth /home/me/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/me/.vnc/passwd -rfbport 5901 -fp /usr/share/fonts/misc:unscaled,/usr/share/fonts/local,/usr/share/fonts/75dpi:unscaled,/usr/share/fonts/100dpi:unscaled,/usr/share/fonts/Type1,/usr/share/fonts/URW,/usr/share/fonts/Speedo,/usr/share/fonts/truetype,/usr/share/fonts/uni,/usr/share/fonts/CID -noreset). That X process is not linked to any actual display hardware. When you VNC to it is the only time it's actually "rendered", although the running x applications believe that they are being rendered all the time.

Hope this helps more.

Ah, okay. I still don't quite understand how that whole thing works, but that's okay; for now I'll just keep it CLI server stuff, and if I decide I really want it, I know of at least one spot where I can find help.

Thanks!