Virtual box and security

[Cosmo.]

No problem, you're welcome.

[Sir Charles]

The point is, that you need to have for a VM more than 1 virtual drive. (Having several partitions on the same virtual drive is not enough, as the drive gets set to write through state, not a partition.) The setting gets done in the manager for virtual drives (ctrl-d from the VB manager) via the change icon. third option in the sub-dialog.

Alright, I got it!

Installing Mint with ubiquity does not work differently in a VM than on bare metal. That means, you go via "something else" in the Mint installer.

Yes, that is what I thought too and I did partition the drive with Gparted but surprisingly it was rejected later by the installer and it returned me several times back to the screen for choosing the installation type. At last I chose "Erase the disk..." option and then the installation went through.

You mean sudoing from the guest?
At first the old story: Never use sudo for launching graphical programs. This will(!) break things in your home.

Yes, I did it in the VM. I should have used "gksudo" of course.

Second: Don't launch VB Manager or any VM with elevated rights. It will(!) break things.

I didn't and I won't! It will(!) break things

Third: "Denies access" in which kind? Error messages?

Error message:

Code: Select all

Failed to open directory "sf_Storage"
Erorr opening directory '/media/sf_Storage': Permission denied.

Is the user account inside of the guest OS (Linux) member of the group vboxsf?

Yes, to the first question. No, to the second. It is just a custom account "minty", now I created a group an added "minty" to it as a member. Was it right thing to do?

Are the guest additions installed inside of the running guest OS?

It seems so:

VMmenu.png

I ran this from the directory where it is mounted sudo sh ./VBoxLinuxAdditions.run
and i got this:

Code: Select all

 /media/minty/VBox_GAs_5.2.6 $ sudo sh ./VBoxLinuxAdditions.run
[sudo] password for minty: 
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.2.6 Guest Additions for Linux........
VirtualBox Guest Additions installer
This system appears to have a version of the VirtualBox Guest Additions
already installed.  If it is part of the operating system and kept up-to-date,
there is most likely no need to replace it.  If it is not up-to-date, you
should get a notification when you start the system.  If you wish to replace
it with this version, please do not continue with this installation now, but
instead remove the current version first, following the instructions for the
operating system.

If your system simply has the remains of a version of the Additions you could
not remove you should probably continue now, and these will be removed during
installation.

Do you wish to continue? [yes or no]

to which, I said no.
Ciao!

[Cosmo.]

Is the user account inside of the guest OS (Linux) member of the group vboxsf?

Yes, to the first question. No, to the second. It is just a custom account "minty", now I created a group an added "minty" to it as a member. Was it right thing to do?

OOps, one question (by me) and two answers? I am confused. Let's try it anyway:
In your guest open Users & Groups. Mark the account on the left side and you see on the right side near the bottom the list of the groups, where the account belongs too. This is actually a button. Click it and you will see a list of the available groups; vboxsf is one of them. Activate it and close all windows. Reboot. Provided, that you had set in the settings for the shared folder to auto-mount it you should see an icon for the folder on your desktop. Or possibly not, because of the most likely missing guest additions. We come to that in the following.

Are the guest additions installed inside of the running guest OS?

It seems so:

No, this only shows, that the iso for the guest additions is mounted, it does say nothing, if they are installed or not.

To find out if and which guest additions are installed press in the running VM host-n (host key is usually the right(!) ctrl key).

From your output I conclude the following:
1. You use Mint 18.2
2. You have not installed the matching guest additions.

To solve this you need to know, that Mint came until 18.2 with some guest additions pre-installed. A silly mistake, as those pre-installed guest additions (GA) near to never matched with the used version of VB - and they have to match! My complaints against that mistake are countless. Only in 18.3 the pre-installed guest additions are finally removed, but in older Mints you have to remove them yourself, before you install the correct GA.
For doing this open in the VM synaptic and search for virtualbox, filter it (left pane) for installed packages. This will give you 3 packages, which you have to completely remove (aka purge). Now you have to reboot the VM before you can install the correct GA.

Now we come to a second problem. Currently the GA for both the latest releases of VB version 5.1.x and 5.2.x have a bug. Usually you should always use the GA, which are provided by the installed version of VB, but in this case you have to download the corrected GA from virtualbox. The corrected GAs are near the top of the download page.

Now mount the iso file in the running VM and open it to install them. Again ou have to reboot the VM to make the installed GA effective.

[Sir Charles]

Is the user account inside of the guest OS (Linux) member of the group vboxsf?

Yes, to the first question. No, to the second.

OOps, one question (by me) and two answers? I am confused.''

I am so sorry, this is so painfully embarrassing. Please let me put the blame on the late hour

In your guest open Users & Groups. Mark the account...

Done! The shared folder was marked to be auto-mounted and it is, no "permission denied" anymore

From your output I conclude the following:
1. You use Mint 18.2

True, the .iso that I loaded up to VB was in fact 18.2. After the install in VM, I upgraded to 18.3 and apparently the outdated guest additions doesn't get updated.

2. You have not installed the matching guest additions.
... but in older Mints you have to remove them yourself...
...you have to download the corrected GA from virtualbox
...mount the iso file in the running VM and open it to install them. Again ou have to reboot the VM to make the installed GA effective

Done! Everything works perfectly now! Here is a shot from right-Ctrl -n:

Screenshot_2018-02-01_22-15-07.png

Mint came until 18.2 with some guest additions pre-installed. A silly mistake, as those pre-installed guest additions (GA) near to never matched with the used version of VB - and they have to match! My complaints against that mistake are countless. Only in 18.3 the pre-installed guest additions are finally removed...

It surely would have saved a lot of time and effort for everybody using VB, had it been removed earlier. Better late than never

Is there anything you think I should do to tighten up the VB's security in case the VM inside is compromised and it get exploited somehow? I am already running it with firejail. I just had to add a line to it's profile to whitelist the shared folder and it works as it should. I can verify it from the host by runningfirejail --list and I can access the content of the shared folder from within the VM.

[Cosmo.]

As long as there is no security hole in VB (which usually gets quickly closed) the guest system cannot do anything outside of the guest system. Shared folders are of course an exception, but it depends if you allow the guest writing in the shard folders. You would surely not store sensible data in a shared folder. IMO using firejail for VB does not make much sense. If you have created a rule which allows the VM writing in a shard folder it has the same effect, as if firejail would not be there. Outside of the shared folder the guest cannot read or write anyway.

Another thing is the shared clipboard. If the guest OS is compromised (your scenario) and you use shared clipboard, the guest can and does of course read and / or write in the clipboard. But in case of a Linux guest the likelihood of a compromised system is as low (or high) as for the Linux host. I personally don't use shared clipboard only for a short time, in case that I need it (usually I do not). Sharing the clipboard can be switched on the fly in the running VM.

Another security aspect is to stay with the default NAT network adapter, if there are no special needs for a different one. It is the most secure one and has also the advantage that it is the quickest one.

One more tip regarding the network settings (not security related): You can select in the advanced network settings as adapter type virtio-net. It is the quickest type and works very well for all current Mints (and most likely for other Linux distros also).

[Sir Charles]

Hi Cosmo.
Pardon me my delay in responding to your last post. I have been playing around a little bit with VB setting up some VMs to figure out the basic functionalities of the VB.
Reading your post, I understand that a completely sealed off VM is the most secure one. Also regarding the network adapter, I have left it to its default, NAT.

One thing that I wonder about is the actual process of allocating hardware resources to a VM. Does it make sense to see VB as creating a "corridor", software-wise, for the guest OS to be run on the hardware, leaving the host OS completely out?

So if this is correct, and assuming that we are running the same OS both in the guest and in the host, then can I conclude that a piece of software that safely can be run in the guest can run safely in the host as well?

Would that apply to kernels too? If I upgrade the kernel to the latest mainline and if it runs without a problem in the VM can I assume that my hardware is still supported by that version?

Or am I wrong about all the assumptions above?

Now to a more practical matter: is it possible to expand an already existing .vdi through Virtual Media Manager?

VB.png

I imagine I should choose "normal" from the menu in order to extend the .vdi. What about those other two options? Is immutable for creating a fix-sized vdi and multi-attach for creating several separated virtual disks which are somehow attached to each other?

MenuVB.png

[Cosmo.]

Regarding the "corridor" question: I am not quite sure, if I understood the question correctly, but reading the following question regarding kernel the answer is No.

VB uses in nearly all parts an own, virtualized hardware: Virtual motherbord with virtual bios, virtual graphics, virtual network and so on. The CPU is the main exception, there the hardware cpu gets used and related BIOS settings are important.

This means, that you cannot test, if a kernel or a driver will work in a hardware environment by testing it in a VM. You will mostly find, that those things work fine in a VM. This is not at least, because numerous developers use VMs to test their software. If it works there, it will near to sure also work for other users, as the virtual hardware is more or less the same. So if a kernel works in the guest it does not necessarily mean that it also works trouble free in the host.

Regarding resizing the virtual drive: This can only be done on the command line and it can only be done, if you selected at the time, when you created the virtual drive to use dynamical size (this is the default setting). I wrote about it in this post.

[Sir Charles]

VB uses in nearly all parts an own, virtualized hardware: Virtual motherbord with virtual bios, virtual graphics, virtual network and so on. The CPU is the main exception, there the hardware cpu gets used and related BIOS settings are important.

I wasn't sure if I had understood the working of VB, but with your explanation things are much more clear now. I was hopeful to be able to test new kernels in a VM and see if my rather low-spec hardware would keep up with the evolution of the kernels but I understand now why it is not possible.

Regarding resizing the virtual drive: This can only be done on the command line and it can only be done, if you selected at the time, when you created the virtual drive to use dynamical size (this is the default setting). I wrote about it in this post.

Yes, I left the default setting unchanged when I created the virtual drive. I will proceed according to your instruction from the link above and I hope I can get back to you with further questions if there are any.

Thank you very much for taking your time to reply to my questions.
regards,
marziano

[Cosmo.]

I was hopeful to be able to test new kernels in a VM and see if my rather low-spec hardware would keep up with the evolution of the kernels but I understand now why it is not possible.

You've got it. It would be as pointless as if you would test a kernel - or a driver - on hardware A and conclude, that it will work exactly the same on hardware B.

This is what I do for such cases: If have a second install of the same Mint version on my computer. In case I want to test something hardware related I boot into this test system. If this should break I have nothing to loose. It only costs some hard drive space.

[Sir Charles]

It would be as pointless as if you would test a kernel - or a driver - on hardware A and conclude, that it will work exactly the same on hardware B.

Sure, I wasn't quite certain how to come in terms with the idea of "virtualized hardware".

This is what I do for such cases: If have a second install of the same Mint version on my computer. In case I want to test something hardware related I boot into this test system. If this should break I have nothing to loose. It only costs some hard drive space.

Nice idea! I better be getting a larger drive. I think I will soon. Will be bothering you all then with questions regarding if there is an optimal and/or ideal partitioning scheme.

[Cosmo.]

Don't hesitate to ask in case of questions. If a discussion runs as nicely as in this case I have a long breath.

[Sir Charles]

What a nice feedback! Thank you!