Disallow dangerous qrexec operations #22
Conversation
|
@adrelanos Does this look good to you? |
|
Perhaps... currently as for this PR: my suggestion: etc.? rationale: ask being a bit more secure than allow. |
|
If going for |
|
Using a config like this appears to work pretty well: Doing this, I can open a file in a new disposable qube, or I can pick an existing disposable qube if I prefer, either one works. However, now the "Open in other qube" button in Thunar doesn't work, because of course it doesn't, this policy explicitly and intentionally breaks it. I can still "Copy to other qube", "Edit in disposable qube", and "View in disposable qube". I guess we need to ask ourselves what's actually worth doing here. Do we assume that any Whonix-Workstation qubes are compromised and therefore the user should have to take the extra step of copying first, so that they don't open a compromised file without thinking long enough? Do we think adding that extra step of annoyance would even help? Given the amount of user interaction needed to cause issues with this kind of a qrexec endpoint, should we even bother? The particular attack scenario I have in mind is basically:
Disabling opening URLs and requiring files to be copied first would likely prevent or at least reduce the risk of this kind of attack succeeding. If we do want to bother with this, we should hide the "Open in other qube" button in Thunar's context menu. |
|
Or, maybe we don't hide the button, maybe we leave it but leave it broken, and try to provide a descriptive error message of some sort so that the user knows why it's broken? That error could then point to documentation of some sort. Edit: I just looked at the qubes-core-agent-linux code for the Thunar context menu options - it looks like it should be (close to) trivial to add a descriptive error message for qvm-open-in-vm failure. I'm not sure if Qubes OS want's a Whonix-specific check here for pointing to some part of our documentation that says "do XYZ if you want this button to work", but in theory it would be doable. Simply hiding the button doesn't seem practical, unless Whonix dpkg-diverts and ships an alternative copy of For now, just going to go ahead with changing the config in a way that will break the button. We should continue to think about how to make this user-friendly in an elegant way. Edit 2: It should be noted, if one has multiple non-disposable Whonix-Workstation qubes open, and attempts to open a file in a disposable qube, they can then proceed to select one of the non-disposable Whonix-Workstation qubes as the qube to open the file in. Not really unexpected given the semantics of the configuration, but ugh, this is ugly no matter how you come at it :P I'm still questioning if this should even be done at all... |
ArrayBolt3
force-pushed
the
arraybolt3/anon-vm-harden
branch
from
4e57403 to
249ffdf
Compare
You can also add a rule |
|
@marmarek That's a really good idea, I'll do that. |
Whonix-Workstation should never need to open a file, URL, or application in anything other than a Whonix-Workstation disposable VM. Allowing it to even ask to do one of these actions in an unsafe way is dangerous, since a user who isn't paying enough attention might allow the request and leak their IP address in so doing (for instance, by visiting an attacker-provided URL in a VM that has clearnet access). Don't allow Whonix-Workstation to take (or ask to take) any of these dangerous actions.
ArrayBolt3
force-pushed
the
arraybolt3/anon-vm-harden
branch
from
249ffdf to
43b89db
Compare
|
@marmarek Suggestion implemented and tested, appears to work! |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025072115-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025061004-4.3&flavor=update
Failed tests14 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/142375#dependencies 11 fixed
Unstable testsPerformance TestsPerformance degradation:8 performance degradations
Remaining performance tests:64 tests
|
Those two indeed looks related to this PR (not #23 ). Normally test assume opening file in a dispvm works without confirmation.
The second option seems better, but also more complex. For the first option, there is The test is in https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/tests/integ/dispvm.py |
|
@marmarek Mostly untested (except for I verified the xdotool code commands would do the right thing if there's only one "Operation execution" window open) attempt at implementing option 2: QubesOS/qubes-core-admin#705 |
Whonix-Workstation should never need to open a file, URL, or application in anything other than a Whonix-Workstation disposable VM. Allowing it to even ask to do one of these actions in an unsafe way is dangerous, since a user who isn't paying enough attention might allow the request and leak their IP address in so doing (for instance, by visiting an attacker-provided URL in a VM that has clearnet access). Don't allow Whonix-Workstation to take (or ask to take) any of these dangerous actions.
Implements QubesOS/qubes-issues#10051.