How secure is windows XP running as a virtualBox guest on a Slackware 12.2 host
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
How secure is windows XP running as a virtualBox guest on a Slackware 12.2 host
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
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.
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
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.
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.
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
Posts: 2,612
Rep:
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
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.