Which default settings have loose security? (InputMouse, VMShell on DispVMs, …)

62 views
Skip to first unread message

Dupéron Georges

unread,
Feb 11, 2019, 10:47:22 AM2/11/19
to qubes-users
These features have a high security cost, and I prefer to disable them.

* Deny /etc/qubes-rpc/policy/qubes.InputMouse . Rationale: BadUSB can
  use the mouse to open a terminal and copy-paste existing characters to
  build a malicious command.
* Deny /etc/qubes-rpc/policy/qubes.VMShell for DispVMs. Rationale: I
  want to use DispVMs for their non-persistent aspect, but want to still
  be able to store confidential data in their base private.img.
* Set "Default DispVM" to "(none)" for most VMs. Rationale: see
  previous point. Most VMs have a specific purpose and do not need to
  open third-party documents in a DispVM anyway.
* Prevent focus stealing (there are several discussions about this on
  GitHub, but no perfect solution so far).
* Let the installation create sys-usb and reboot immediately (USB is
  still enabled in Dom0 until the next reboot).

Some other features are covered by the Security Guides (NetVM = none,
firewall, Anti Evil Maid, possibly disable passwordless sudo)

Are there any other settings that one should change after installation
to improve Qube's security?

Cheers,
Georges Dupéron

Chris Laprise

unread,
Feb 11, 2019, 2:51:13 PM2/11/19
to Dupéron Georges, qubes-users
On 2/11/19 9:39 AM, Dupéron Georges wrote:
> These features have a high security cost, and I prefer to disable them.
>
> * Deny /etc/qubes-rpc/policy/qubes.InputMouse . Rationale: BadUSB can
>   use the mouse to open a terminal and copy-paste existing characters to
>   build a malicious command.

I'm not sure about this. A mouse cursor that is blind to screen content
and its own position is very limited.

> * Deny /etc/qubes-rpc/policy/qubes.VMShell for DispVMs. Rationale: I
>   want to use DispVMs for their non-persistent aspect, but want to still
>   be able to store confidential data in their base private.img.

Have a look at https://github.com/tasket/Qubes-VM-hardening

It provides some of the protection that dispVMs have, while letting data
persist in the private volume. It also gives the user control over which
files can remain, sha256 checks, and protects against common methods for
malware escalation and persistence.

> * Set "Default DispVM" to "(none)" for most VMs. Rationale: see
>   previous point. Most VMs have a specific purpose and do not need to
>   open third-party documents in a DispVM anyway.
> * Prevent focus stealing (there are several discussions about this on
>   GitHub, but no perfect solution so far).
> * Let the installation create sys-usb and reboot immediately (USB is
>   still enabled in Dom0 until the next reboot).

Focus-stealing is a real issue that I would like to see addressed. FWIW,
KDE will prevent focus-stealing most of the time, but at the expense of
having any automatic focus.

>
> Some other features are covered by the Security Guides (NetVM = none,
> firewall, Anti Evil Maid, possibly disable passwordless sudo)
>
> Are there any other settings that one should change after installation
> to improve Qube's security?

I would suggest looking at Apparmor. Years ago it had problems working
correctly with Firefox but has supposedly improved since then.

I would also move most VM functions to Debian. Despite recent drama over
apt, its still more secure overall than Fedora. The latter is uniquely
deprived of proper repository signatures to satisfy Red Hat's marketing
department... its been a long-term thorn in Qubes' side.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

awokd

unread,
Feb 13, 2019, 5:55:53 PM2/13/19
to qubes...@googlegroups.com
Chris Laprise wrote on 2/11/19 7:51 PM:

> I would also move most VM functions to Debian. Despite recent drama over
> apt, its still more secure overall than Fedora. The latter is uniquely
> deprived of proper repository signatures to satisfy Red Hat's marketing
> department... its been a long-term thorn in Qubes' side.

Could one say apt's security lapse is Fedora's every day? :)

Reply all
Reply to author
Forward
0 new messages