Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

If a call is made to qubes.Service from dom0, qrexec doesn’t check for qubes.Service+, only qubes.Service #9090

Closed
DemiMarie opened this issue Apr 4, 2024 · 0 comments · Fixed by QubesOS/qubes-core-qrexec#139
Closed

If a call is made to qubes.Service from dom0, qrexec doesn’t check for qubes.Service+, only qubes.Service #9090

DemiMarie opened this issue Apr 4, 2024 · 0 comments · Fixed by QubesOS/qubes-core-qrexec#139
Assignees
@DemiMarie
Labels
affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. C: core diagnosed Technical diagnosis has been performed (see issue comments). P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@DemiMarie
Copy link

How to file a helpful issue

Qubes OS release

R4.2, but R4.1 is probably also affected.

Brief summary

If dom0 makes a call to qubes.Service (perhaps via qvm-run --service VMNAME qubes.Service), there is no check for /etc/qubes-rpc/qubes.Service+ (with explicit empty argument), only /etc/qubes-rpc/qubes.Service (with no argument).

Steps to reproduce

See above.

Expected behavior

/etc/qubes-rpc/qubes.Service+ is preferred.

Actual behavior

/etc/qubes-rpc/qubes.Service+ is not searched for.
@DemiMarie DemiMarie added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. diagnosed Technical diagnosis has been performed (see issue comments). affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. labels Apr 4, 2024
@DemiMarie DemiMarie self-assigned this Apr 4, 2024
@DemiMarie DemiMarie added the pr submitted A pull request has been submitted for this issue. label Apr 7, 2024
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue Apr 7, 2024
@DemiMarie
Add test for missing service arguments
b16e0a5 
The test currently fails due to QubesOS/qubes-issues#9090.  The test for
socket services will be added along with the fix, as without the fix it
hangs.
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue Apr 7, 2024
@DemiMarie
Search for qubes.Service+ if call for qubes.Service is made
25bad5c 
Previously, qubes.Service+ was searched for if the call was from a VM,
but not if the call was from dom0.  Furthermore, a call from dom0 with
no argument would skip the check for a too-long service name.

In the future, service arguments should be required and not passing one
should be treated as an error.  That's for R5.0, though: there is too
much code in dom0 that depends on the current behavior, and Mirage also
depends on receiving a call with no argument at all.

QREXEC_SERVICE_FULL_NAME (for executable services) and the call metadata
(for socket services) still include the actual command, even if the
command does not include "+".  Therefore, code that needs to
differentiate between "no argument" and "empty argument" can do so for
calls from dom0.

Fixes: QubesOS/qubes-issues#9090
@DemiMarie DemiMarie mentioned this issue Apr 7, 2024
Merged
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue Apr 9, 2024
@DemiMarie
Search for qubes.Service+ if call for qubes.Service is made
b74ed8f 
Previously, qubes.Service+ was searched for if the call was from a VM,
but not if the call was from dom0.  Furthermore, a call from dom0 with
no argument would skip the check for a too-long service name.

In the future, service arguments should be required and not passing one
should be treated as an error.  That's for R5.0, though: there is too
much code in dom0 that depends on the current behavior, and Mirage also
depends on receiving a call with no argument at all.

QREXEC_SERVICE_FULL_NAME (for executable services) and the call metadata
(for socket services) still include the actual command, even if the
command does not include "+".  Therefore, code that needs to
differentiate between "no argument" and "empty argument" can do so for
calls from dom0.

Fixes: QubesOS/qubes-issues#9090
DemiMarie added a commit to DemiMarie/qubes-core-qrexec that referenced this issue Apr 9, 2024
@DemiMarie
Search for qubes.Service+ if call for qubes.Service is made
0326d84 
Previously, qubes.Service+ was searched for if the call was from a VM,
but not if the call was from dom0.  Furthermore, a call from dom0 with
no argument would skip the check for a too-long service name.

In the future, service arguments should be required and not passing one
should be treated as an error.  That's for R5.0, though: there is too
much code in dom0 that depends on the current behavior, and Mirage also
depends on receiving a call with no argument at all.

QREXEC_SERVICE_FULL_NAME (for executable services) and the call metadata
(for socket services) still include the actual command, even if the
command does not include "+".  Therefore, code that needs to
differentiate between "no argument" and "empty argument" can do so for
calls from dom0.

Fixes: QubesOS/qubes-issues#9090
This was referenced May 9, 2024
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@DemiMarie DemiMarie

Labels
affects-4.1 This issue affects Qubes OS 4.1. affects-4.2 This issue affects Qubes OS 4.2. C: core diagnosed Technical diagnosis has been performed (see issue comments). P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Various bugfixes DemiMarie/qubes-core-qrexec
2 participants
@DemiMarie @andrewdavidwong