Project

General

Profile

Feature #5730

Virtualbox guest additions: enable by default the display management service

Added by Tails about 6 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Category:
Virtualization
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
feature/5730-enable-virtualbox-guest-additions
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

Description

When running tails as a Virtualbox guest, the display management service is disabled by default. Thus the "auto-resize guest display" option in Virtualbox doesn't work. It can be enabled by the following command:

sudo VBoxClient --display

This could be made default if there is no security risk involved.

<blockquote>

/etc/X11/Xsession.d/98vboxadd-xclient already tries to start this service, but fails: Failed to connect to the VirtualBox kernel service in ~/.xsession-errors. Giving the default user read/write access to /dev/vboxuser allows her to run VBoxClient --display without being root.

The virtualbox-guest-dkms Debian package ships the udev rules that should fix these permissions, but we intentionally remove this package at build time after having built the modules.

One should change config/chroot_local-hooks/50-virtualbox to duplicate the udev rules file installed by virtualbox-guest-dkms.

<blockquote>

I'm not convinced we want to do this. First, auto-resize guest display results in super weird resolutions that are essentially unique identifiers. The only application I'm aware of leaking the resolution is Iceweasel. Torbutton does stuff here which maybe is good enough (setting desktop resolution to window size rounded to multiples of 50, I believe). OTOH a VirtualBox host with guest additions installed has a pretty ok selection of resolutions, and user-set resolutions will be remembered and re-set by the guest additions. Isn't that good enough?

Second, if we give the amnesia user permission to /dev/vboxuser it can also enable clipboard sharing at will. Of course, since the amnesia user is a passwordless sudoer it currently can do that any way, but when tails-greeter is released it won't. Tthe default when creating a VirtualBox appliance is bi-directional clipboard sharing, and hence a compromised Tails session results in the Tails session always having access to the host's clipboard. The user could of course disable clipboard sharing in the VirtualBox guest appliance settings when not needed, but I don't expect users to think about this.

Conslusion: If we think auto-resizing is important and safe, we should enable it by default without giving the user access to /dev/vboxuser. I suppose we could also activate clipboard sharing, but only in the Tails -> host direction.

Until someone gives us convincing arguments for the above this bug is marked wontfix => .

</blockquote>

</blockquote>


Related issues

Related to Tails - Bug #7728: Suboptimal display resolution in VirtualBox Rejected 08/02/2014

Associated revisions

Revision c57dcf4a (diff)
Added by Tails developers almost 5 years ago

Enable VirtualBox guest additions by default (Closes: #5730)

Revision 54a53b32 (diff)
Added by Tails developers over 4 years ago

Enable VirtualBox guest additions by default (Closes: #5730)

Conflicts:
config/chroot_local-hooks/50-virtualbox

This change was lost in feature/jessie in the conflict resolution of
merge dfe65a7.

History

#1 Updated by intrigeri about 6 years ago

  • Type of work set to Code

Type of work: Code

#2 Updated by intrigeri about 5 years ago

  • Description updated (diff)
  • Starter set to No

FWIW, in libvirt/Spice environments, we do have auto-resizing available. The user can enable or disable it from their Spice client, on the host system.

#3 Updated by sajolida about 5 years ago

  • Status changed from Resolved to New

I'm talking about VirtualBox as proposed for Tails 1.1, that is VirtualBox 4.3.10 on both the host and the guest.

Regarding the display resizing:

  • Even without the udev rules, which means with VBoxClient restricted to root, it is possible to resize the display non-automatically through Applications → System Tools → Preferences → System Settings. So that weakens the argument about avoiding weird sizes.
  • In this Displays utility, the only two resolutions that are proposed are 800x600 and the window size (unique identifier). So if I want something better than 800x600 I'll get a unique identifier anyway, with or without administration privileges. At least here, I can't set any other standard display size.
  • The default resolution I'm getting at Tails Greeter (800x600) works but I have to scroll to see all the options.
  • The screen resolution is remembered from one session to the other.

Regarding the shared clipboard:

  • The availability of the shared clipboard is defined in the configuration of the guest on the host. It can be set to Disabled, Host to Guest, Guest to Host, and Bidirectional, but always from the host. And it is set to Disabled by default. So having the udev rules does not mean having the clipboard of the host available in Tails by default.
  • I'm not sure it is possible to limit the direction of the clipboard from inside the guest. The man page of VBoxClient only suggests that it is possible to activate the shared clipboard in the guest (and as configured from the host).

#4 Updated by anonym about 5 years ago

sajolida wrote:

I'm talking about VirtualBox as proposed for Tails 1.1, that is VirtualBox 4.3.10 on both the host and the guest.

... and with a 32-bit guest (or at least with the 32-bit kernel forced), I suppose.

Regarding the display resizing:

  • Even without the udev rules, which means with VBoxClient restricted to root, it is possible to resize the display non-automatically through Applications → System Tools → Preferences → System Settings. So that weakens the argument about avoiding weird sizes.

I can confirm this, and actually it's even worse since (at least for me) the default I get is to sync the guest resolution to the window size on the host.

  • In this Displays utility, the only two resolutions that are proposed are 800x600 and the window size (unique identifier). So if I want something better than 800x600 I'll get a unique identifier anyway, with or without administration privileges. At least here, I can't set any other standard display size.

In addition, I get 1024x768. Could this be related to the host's resolution? My thinking is that guest resolutions with any dimension larger than that of the host's resolution are hidden in the guest. As a data point, I use my screen's 1600x900 native resolution.

  • The default resolution I'm getting at Tails Greeter (800x600) works but I have to scroll to see all the options.

What happens if you resize your window to something "strange" and reboot? I get the "strange" resolution as default, as I mentioned above. And for new VMs I get 1024x768 (presumably since thet's the default window size given my host's resolution).

  • The screen resolution is remembered from one session to the other.

To me it seems what actually is remembered is the window size, that then determines the guest resolution. At lest with the display management service off.

Regarding the shared clipboard:

  • The availability of the shared clipboard is defined in the configuration of the guest on the host. It can be set to Disabled, Host to Guest, Guest to Host, and Bidirectional, but always from the host. And it is set to Disabled by default. So having the udev rules does not mean having the clipboard of the host available in Tails by default.

I can confirm that at least in VirtualBox from Debian Wheezy (4.3.10-dfsg-1~bpo70+1) the default is to have clipboard sharing disabled. I think the default was bi-directional at some point though, for whatever it's worth.

  • I'm not sure it is possible to limit the direction of the clipboard from inside the guest. The man page of VBoxClient only suggests that it is possible to activate the shared clipboard in the guest (and as configured from the host).

I couldn't find anything on this either.

#5 Updated by sajolida about 5 years ago

... and with a 32-bit guest (or at least with the 32-bit kernel
forced), I suppose.

Yes.

  • In this Displays utility, the only two resolutions that are
    proposed are 800x600 and the window size (unique identifier). So if
    I want something better than 800x600 I'll get a unique identifier
    anyway, with or without administration privileges. At least here, I
    can't set any other standard display size.

In addition, I get 1024x768. Could this be related to the host's
resolution? My thinking is that guest resolutions with any dimension
larger than that of the host's resolution are hidden in the guest. As
a data point, I use my screen's 1600x900 native resolution.

I'm not sure. My host is 1280x800 so 1024x768 should fit in, but maybe
that's too tight to offer 1280x800 in a host.

  • The default resolution I'm getting at Tails Greeter (800x600)
    works but I have to scroll to see all the options.

What happens if you resize your window to something "strange" and
reboot? I get the "strange" resolution as default, as I mentioned
above. And for new VMs I get 1024x768 (presumably since thet's the
default window size given my host's resolution).

Yes, if I reboot I get back to the previous screen resolution by default.

  • The screen resolution is remembered from one session to the
    other.

To me it seems what actually is remembered is the window size, that
then determines the guest resolution. At lest with the display
management service off.

Yes, that's saved in the configuration file of the VM as
GUI/LastGuestSizeHint:

&lt;ExtraDataItem name="GUI/LastGuestSizeHint" value="599,656"/&gt;

Note that this is the last screen resolution but not the window size.
Because if I reboot the VM the window goes back to the last screen
resolution, and not window size.

#6 Updated by intrigeri about 5 years ago

With all this info in hand, and the fact our browser now hides the screen resolution quite well, I personally find it is fine to support auto-resizing of guests.
Regarding clipboard sharing, if it's off by default, I have no concern either.
In short, I'm in favor of marking this ticket "Confirmed".

(Note that these concerns are shared with the Spice/QXL virtualization environment, as we're running spice-vdagent. No idea what the defaults are there. Off-topic, would need a dedicated ticket if we care.)

#7 Updated by intrigeri about 5 years ago

  • Category set to Hardware support
  • Status changed from New to Confirmed
  • Priority changed from Normal to Low

OK, marking as confirmed. Any taker, feel free to assign this ticket to yourself, and adjust the priority as you see fit.

#8 Updated by sajolida about 5 years ago

  • Assignee set to sajolida

#9 Updated by sajolida almost 5 years ago

  • Related to Bug #7728: Suboptimal display resolution in VirtualBox added

#10 Updated by sajolida almost 5 years ago

  • Target version set to Tails_1.2

#11 Updated by intrigeri almost 5 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from sajolida to anonym
  • % Done changed from 0 to 50

Reassigning to anonym, as sajolida said on tails-dev@ he did.

#12 Updated by sajolida almost 5 years ago

  • QA Check set to Ready for QA

#13 Updated by anonym almost 5 years ago

  • Feature Branch set to feature/5730-enable-virtualbox-guest-additions

#14 Updated by anonym almost 5 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#15 Updated by anonym almost 5 years ago

  • Status changed from Fix committed to Resolved

#16 Updated by sajolida over 4 years ago

  • Category changed from Hardware support to Virtualization

Also available in: Atom PDF