[hsbauauvhabzb]

In what scenario can you read/modify virtual box vms on a shared system in which you can’t read enough of a user profile to compromise an active user session to compromise encrypted credentials?

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.

[justsomehnguy]

> In what scenario can you read/modify virtual box vms on a shared system in which you can’t read enough of a user profile to compromise an active user session to compromise encrypted credentials?

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...