protecting VDI images and iSCSI raw devices

[Daniel Pocock]

In the default deployment of a VDI, the VDI (or equivalent file) is
readable and writeable by the UNIX user running VirtualBox

For people using iSCSI, the iSCSI credentials are stored in a
configuration file that is readable by the UNIX user who runs VirtualBox

In both cases, this means that the UNIX user can modify the raw VDI
filesystem contents, possibly modifying scripts that would run with root
privileges or just breaking the VDI in some way that requires extra
support effort.

Is there any way to have the VDI file or settings owned by a system user
(e.g. a user called vbox) such that they would only be accessible to the
hypervisor and the user can only interact with the VM through the GUI?

[jdd]

Post by Daniel Pocock
In the default deployment of a VDI, the VDI (or equivalent file) is
readable and writeable by the UNIX user running VirtualBox
For people using iSCSI, the iSCSI credentials are stored in a
configuration file that is readable by the UNIX user who runs VirtualBox
In both cases, this means that the UNIX user can modify the raw VDI
filesystem contents, possibly modifying scripts that would run with root
privileges or just breaking the VDI in some way that requires extra
support effort.
Is there any way to have the VDI file or settings owned by a system user
(e.g. a user called vbox) such that they would only be accessible to the
hypervisor and the user can only interact with the VM through the GUI?

why don't you run it as vbox user, and keep this user private?

access to the virtual machine have no relation with the user running the box

jdd

[Daniel Pocock]

Post by jdd

Post by Daniel Pocock
In the default deployment of a VDI, the VDI (or equivalent file) is
readable and writeable by the UNIX user running VirtualBox
For people using iSCSI, the iSCSI credentials are stored in a
configuration file that is readable by the UNIX user who runs VirtualBox
In both cases, this means that the UNIX user can modify the raw VDI
filesystem contents, possibly modifying scripts that would run with root
privileges or just breaking the VDI in some way that requires extra
support effort.
Is there any way to have the VDI file or settings owned by a system user
(e.g. a user called vbox) such that they would only be accessible to the
hypervisor and the user can only interact with the VM through the GUI?

why don't you run it as vbox user, and keep this user private?
access to the virtual machine have no relation with the user running the box

How does that work in practice though? Is there a recommended way to
set this up?

Do you mean running the VirtualBox GUI as user vbox with sudo?

[jdd]

Post by Daniel Pocock

Post by jdd
access to the virtual machine have no relation with the user running the box

How does that work in practice though? Is there a recommended way to
set this up?
Do you mean running the VirtualBox GUI as user vbox with sudo?

I used this on my server last year, virtualbox started automatically at boot,
all vbomanage (CLI). Standard with openSUSE.

practically I use GUI only for initial setup, after wich I have no reason to
use it again, so I stop the virtual machine and start it again by command line

basics here:

http://dodin.info/wiki/index.php?n=Doc.VirtualBoxHost

jdd
(I do not use it anymore, because using virtual server is too much complicated
for my simple use)

[Kees Nuyt]

Post by Daniel Pocock
In the default deployment of a VDI, the VDI (or equivalent file) is
readable and writeable by the UNIX user running VirtualBox
For people using iSCSI, the iSCSI credentials are stored in a
configuration file that is readable by the UNIX user who runs VirtualBox
In both cases, this means that the UNIX user can modify the raw VDI
filesystem contents, possibly modifying scripts that would run with root
privileges or just breaking the VDI in some way that requires extra
support effort.
Is there any way to have the VDI file or settings owned by a system user
(e.g. a user called vbox) such that they would only be accessible to the
hypervisor and the user can only interact with the VM through the GUI?

I can think of two ways. In both, the VBox processes would run
as some other user, protected against interference by the end
user.

1. Have the VM started by the host.
Connect to the VM using RDP or VNC.

2. Use sudo to give the end user access
to just the commands and subcommands
he needs to stop/start his VM.

Disclaimer: I didn't try any of these myself.

[Pierre Malard]

Post by Daniel Pocock
In the default deployment of a VDI, the VDI (or equivalent file) is
readable and writeable by the UNIX user running VirtualBox
For people using iSCSI, the iSCSI credentials are stored in a
configuration file that is readable by the UNIX user who runs VirtualBox
In both cases, this means that the UNIX user can modify the raw VDI
filesystem contents, possibly modifying scripts that would run with root
privileges or just breaking the VDI in some way that requires extra
support effort.
Is there any way to have the VDI file or settings owned by a system user
(e.g. a user called vbox) such that they would only be accessible to the
hypervisor and the user can only interact with the VM through the GUI?

That’s true but not only for a unix user. You can do everything you wrote on Windows also.

On a *nix OS you can play with ACL rules and/or with a specific user to virtualbox users and a sudo configuration. But, if the user know that, he can also modify the VDI file with a 
 sudo command on host OS. You can also use a specific command which play virtualbox with specific rights
.
--
Pierre Malard

« Il faut créer en même temps les élites et les débouchés, le syndica-
lisme et les usines. Faire l'un sans l'autre, c'est travailler pour le
malheur du peuple. »
Romain Gary - "Les racines du ciel"
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--