3 ms·

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

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 4y ago
> 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#vmencryption https://www.virtualbox.org/manual/UserManual.html#vmencrypti...