-
-
Notifications
You must be signed in to change notification settings - Fork 50
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.
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
MSG_TRIGGER_SERVICE3
and MSG_TRIGGER_SERVICE
behave inconsistently on invalid service names
#9098
Closed
Labels
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.
Comments
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
Apr 7, 2024
There is no point in allowing calls with an empty service name: if the argument was empty, the call would be unconditionally rejected by the policy daemon, and even if it was _not_ empty, libqrexec would refuse to execute the call. Furthermore, MSG_TRIGGER_SERVICE3 already checks for empty service names and sends MSG_SERVICE_REFUSED without even querying the policy daemon, so querying the policy daemon for MSG_TRIGGER_SERVICE is inconsistent. Fixes: QubesOS/qubes-issues#9098
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
Apr 7, 2024
There is no point in allowing calls with an empty service name: if the argument was empty, the call would be unconditionally rejected by the policy daemon, and even if it was _not_ empty, libqrexec would refuse to execute the call. Furthermore, MSG_TRIGGER_SERVICE3 already checks for empty service names and sends MSG_SERVICE_REFUSED without even querying the policy daemon, so querying the policy daemon for MSG_TRIGGER_SERVICE is inconsistent. Fixes: QubesOS/qubes-issues#9098
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
Apr 8, 2024
There is no point in allowing calls with an empty service name: if the argument was empty, the call would be unconditionally rejected by the policy daemon, and even if it was _not_ empty, libqrexec would refuse to execute the call. Furthermore, MSG_TRIGGER_SERVICE3 already checks for empty service names and sends MSG_SERVICE_REFUSED without even querying the policy daemon, so querying the policy daemon for MSG_TRIGGER_SERVICE is inconsistent. Fixes: QubesOS/qubes-issues#9098
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
Apr 9, 2024
There is no point in allowing calls with an empty service name: if the argument was empty, the call would be unconditionally rejected by the policy daemon, and even if it was _not_ empty, libqrexec would refuse to execute the call. Furthermore, MSG_TRIGGER_SERVICE3 already checks for empty service names and sends MSG_SERVICE_REFUSED without even querying the policy daemon, so querying the policy daemon for MSG_TRIGGER_SERVICE is inconsistent. Fixes: QubesOS/qubes-issues#9098
DemiMarie
added a commit
to DemiMarie/qubes-core-qrexec
that referenced
this issue
Apr 9, 2024
There is no point in allowing calls with an empty service name: if the argument was empty, the call would be unconditionally rejected by the policy daemon, and even if it was _not_ empty, libqrexec would refuse to execute the call. Furthermore, MSG_TRIGGER_SERVICE3 already checks for empty service names and sends MSG_SERVICE_REFUSED without even querying the policy daemon, so querying the policy daemon for MSG_TRIGGER_SERVICE is inconsistent. Fixes: QubesOS/qubes-issues#9098
This was referenced May 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.
How to file a helpful issue
Qubes OS release
R4.2. R4.1 doesn’t have the check at all so there is nothing to be inconsistent about.
Brief summary
MSG_TRIGGER_SERVICE3
andMSG_TRIGGER_SERVICE
behave inconsistently on invalid service names (empty or start with a+
)Steps to reproduce
Implement a qrexec agent that sends an old-style
MSG_TRIGGER_SERVICE
request with a name that starts with NUL or+
.Expected behavior
Qrexec policy engine not invoked with this invalid name, as would happen if
MSG_TRIGGER_SERVICE3
was used.Actual behavior
Qrexec policy engine invoked with this invalid name.
The text was updated successfully, but these errors were encountered: