How do I prevent any outside access - that I do not initiate - to an XP guest running on a slackware host.

I have a shared folder defined that allows data from the xp guest to be accessed in the slackware host. Is this something that might allow something bad to get from the xp guest into the slackware host

Gary

If there's a connection between the host and your virtual, then your virtual is not completely isolated. Therefore, the virtual can be compromised. If a hacker gains access to the host, then if you virtual is running in that host, he can then gain access to the virtual. Only way to make that virtual 100% secure is to cut off all access to the host. Of course, if you have that virtual have ports open to the internet or even surf on the internet, then I'm sure it's still vulnerable.

Thanks for the comments, Trist007.

I'm more concerned about the slackware host being compromised by something that gets into the XP virtual.

My host Lan is 192.*.*.*; VBox sets up the guest with an ip address like 10.*.*.*; and there is no network connection between the host and the guest (although the guest has internet access by way of a virtual network adapter); But there is a shared folder that VBox provides - that would appear to be the crack in the works between the two

Gary

Your biggest security risks will come from opening email messages or viewing web pages using Windows XP in the virtual machine. A broadband router blocks connections from outside and the NAT interface in VirtualBox also blocks connections from outside. The only way to be completely secure is to allow no network access from the Windows XP system. Shared folders are not a big security concern but keep in mind that running programs or opening files that came from outside the virtual machine can infect the OS in the virtual machine.

The user is the biggest security risk and the hardest one to protect against. Opening or running infected files, viewing infected web content or allowing administrator functions from software are all ways that a user can compromise security.

Linux isn't virus proof either. The odds are lower but there is still a chance of Linux being infected by malware targeted toward Linux. Usually a virus for Windows or Linux doesn't infect a different OS but there are exceptions.

Back up your software and virtual disks. People often forget that malware isn't the only thing that can make an OS fail. Security is about minimizing lost time and information due to any kind of problem. It also makes sense to focus on the most important information or software. There is no way to make any system 100% secure and it makes no sense to spend a lot of time protecting something that will take less time to restore or replace.

Bugs in VirtualBox have been more of a "Security" risk for me than anything else. I've lost a few virtual disk images. One thing that I've discovered is that sharing a virtual disk file between Windows and Linux is likely to corrupt the virtual disk. So a security precaution is to only write to a virtual disk file using one version of VirtualBox on one OS.

Thanks, Erik, for the excellent description.

I think I'm ok. I'v only got a couple of windows applications that I really need; and I'm not sharing a virtual disk file, what I'm doing is copying the windows virtual disk application data to-and-from a shared linux file on the linux host
(my VBox is version 2.1.0; share set up using
"virtual machine devices tab" ---> "shared folders tab")

I just dont want my tinkering on the virtual machine to release a plaague on the host. From your description, sounds like all is well.

Gary

for that purpose, however there is one advantage.. simply create a duplicate copy of the guest's virtual hard drive image and store it somewhere, and if you suspect the windows on the guest hd is infected or something, simply torch the running copy and replace it with a copy of the backup you made
but yeah, as long as the communication between guest OS and host OS is minimum, there should be minimal risk as a virtual machine is in effect a type of 'sandbox', that for a lage part doesn't even directly talk to the hardware

1 members found this post helpful.

That's a good point and VirtualBox supports "immutable" disks that can be used in cases where you want to maintain a "known good" base and then save all the changes to the disk from there. Those can be used to always start out with the same exact OS and files or provide a "checkpoint" snapshot of the OS.

Copying virtual disk images works too. Just remember that VirtualBox can't access more than one copy of the same virtual disk even when the copies have different file names. To make a unique copy of a disk you have to use "vboxmanage". That changes the internal UUID for the disk image and makes it a completely different virtual disk.

Best as mentioned, to have a clean backup of your XP guest so if XP is compromised, you can simply overwrite it with the clean backup. As far as security and VBox Shares, that doesn't matter, yes it is somewhat of a link to your Linux Host but for someone maliciously accessing your computer through the XP guest, they will still need your host ROOT password to access the host which they'll most likely never get, worst case you'll have a compromised XP guest install that they could delete files in the VBox share folder (if it allows w-x permissions that is). I run XP guest on my Linux host and don't worry about it, it has full access to internet - which i mostly only use to update Malwarebytes, Super-Anit-Spyware, and my virus software, occasionally I use TeamViewer - but for e-mail and surfing etc, do that from the host ( there's no advantage to surfing in XP guest ). Having a complete backup is better than running/accumulating vbox snapshots - I don't use the snapshots at all.

I backup my VirtualBox guests by running rsync in a terminal, back them up to a backup directory - here is an example assuming the backup directory is mounted in /mnt :
Where <USERNAME> is your user name, and <BACKUPDIRECTORY> is where you're backing up VirutalBox to. The above example will backup all of your guests in VirtualBox, if you want to backup only the XP guest, then append its directory to the end of "VirtualBox\ VMs/" in both the from and to parts of the command. To overwrite an existing guest from a good backup, simpy reverse the from and to sections of the above command. This also works very well for say you install some software in XP that you decide you don't want - rather than doing Windows uninstall software, simply overwrite your XP guest with your backup - it is much cleaner, because you know when you leave windows open in your house, flies come and go as they please but they always leave some crap behind...

Not sure how much help it'll be 6 years after the fact, but a good reply none the less.

1 members found this post helpful.

in most cases Ops are running XP in a VB in order to use some proprietary based
software that runs best under win_xp & thus there is rarely a need
to give it any form of external connection at all.

but: it is easy to switch any connection ON/OFF from the host O/S - as required.

1 members found this post helpful.

oops, somehow i thought it was only 6mo's old not 6yrs! thanks rkelson

Since the thread has been resurrected, I will mention that Oracle has recently made VirtualBox much more secure in the host OS. It is now much harder for exploits in the host OS to affect or compromise virtual machines running as VirtualBox guests. As always, visit the VirtualBox web site for lots of useful information.

1 members found this post helpful.

Well, even tho it's an old post, I still benefited from finding this post.

One thing to note if you are going to rsync, you can rsync backup the VirtualBox guest while it is running however, if you are doing things in the guest at the time files will be changing. But, if you are going to overwrite an existing guest with a backup, make sure to shut down the guest first. Or that is my understanding - I have rsync'd backups while the guest was running and used them later to replace the guest without issue so long as the guest is not running during the overwrite process. And as Erik already mentioned, the Oracle site has a lot of helpful information.