undefined | Better HN

0 pointsjustsomehnguy3y ago0 comments

> If the host is compromised at a privilege level able to read

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.

0 comments

hsbauauvhabzb3y 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?

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.

justsomehnguyOP3y 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#vmencrypti...

j / k navigate · click thread line to collapse