You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The qube property default_dispvm can cause network leaks and allows qubes that create it to run commands on other qubes.
Steps to reproduce
Create a qube from any formula (most) that doesn't unset default_dispvm and run qubes.VMShell.
Expected behavior
No dispvm can be created from qubes that don't need it according to the Qube connections design.
Actual behavior
Qube with no network can run commands on on networked qube or from a different network.
Note this is not a degradation over Qubes default settings, it is the same default setting as upstream. Also not that if you have the reader formula, the dvm-reader becomes the global default_dispvm, which is non-networked and makes things less dangerous.
This change can be somewhat difficult to convey for users depending on how they use the formula, but we must enforce it for security reasons. Let's give some exampels:
Should vault, sys-pgp or sys-ssh-agent have it? No, it only manages passwords and keys created in it. But there may be cases in the future where the split-gpg2 opens a message to be signed in a disposable qube that will be created by sys-pgp, so a default_dispvm must be set. But until that is the case, unset it.
Should a disposable, a disposable template or a template have it? In most cases, again, no. Avoid chains of disposable qubes.
Should qubes that runs applications that manages files have it (browser, element, signal)? Yes, this is the targetted use case.
Should system qubes have it? In most cases, no, sys-net, sys-firewall, sys-pihole don't really need it, but other qubes that store files may need it, such as sys-syncthing, sys-rsync, to open the files securely in a disposable.
What about the other cases? To be decided how to handle it.
The text was updated successfully, but these errors were encountered:
Brief summary
The qube property
default_dispvm
can cause network leaks and allows qubes that create it to run commands on other qubes.Steps to reproduce
Create a qube from any formula (most) that doesn't unset
default_dispvm
and runqubes.VMShell
.Expected behavior
No dispvm can be created from qubes that don't need it according to the Qube connections design.
Actual behavior
Qube with no network can run commands on on networked qube or from a different network.
Note this is not a degradation over Qubes default settings, it is the same default setting as upstream. Also not that if you have the
reader
formula, thedvm-reader
becomes the globaldefault_dispvm
, which is non-networked and makes things less dangerous.This change can be somewhat difficult to convey for users depending on how they use the formula, but we must enforce it for security reasons. Let's give some exampels:
Should vault, sys-pgp or sys-ssh-agent have it? No, it only manages passwords and keys created in it. But there may be cases in the future where the split-gpg2 opens a message to be signed in a disposable qube that will be created by sys-pgp, so a default_dispvm must be set. But until that is the case, unset it.
Should a disposable, a disposable template or a template have it? In most cases, again, no. Avoid chains of disposable qubes.
Should qubes that runs applications that manages files have it (browser, element, signal)? Yes, this is the targetted use case.
Should system qubes have it? In most cases, no, sys-net, sys-firewall, sys-pihole don't really need it, but other qubes that store files may need it, such as sys-syncthing, sys-rsync, to open the files securely in a disposable.
What about the other cases? To be decided how to handle it.
The text was updated successfully, but these errors were encountered: