Skip to content

Fix PrinterSpooler D-Bus signal spoofing - #1690

Closed
oubayashi wants to merge 1 commit into
OpenPrinting:masterfrom
oubayashi:master
Closed

Fix PrinterSpooler D-Bus signal spoofing#1690
oubayashi wants to merge 1 commit into
OpenPrinting:masterfrom
oubayashi:master

Conversation

@oubayashi

Copy link
Copy Markdown
Contributor

The existing policy grants root permission to send messages on the
com.redhat.PrinterSpooler interface, but does not deny unprivileged
clients. Since the system bus permits broadcast signals by default, an
ordinary user can emit a spoofed PrinterSpooler signal despite the
comment claiming that only root can send it.

Deny signals on this interface in the default policy and allow them
again for root. This preserves reception for all connections and limits
the change to signal messages, avoiding an unintended restriction on
other message types.

@oubayashi oubayashi closed this Sep 2, 2026
@oubayashi oubayashi reopened this Sep 2, 2026
@oubayashi

oubayashi commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

I was able to reproduce this locally with a regular, non-root user.
Even though cups.conf says that only root can send the message, the
following command succeeds and is visible to listeners:

dbus-send --system --type=signal /com/redhat/PrinterSpooler com.redhat.PrinterSpooler.PrinterAdded string:fake

It looks like the current rule only allows root, but does not explicitly
deny anyone else. Since the system bus allows broadcast signals by
default, regular users can spoof these notifications too.

The existing policy grants root permission to send messages on the
com.redhat.PrinterSpooler interface, but does not deny unprivileged
clients. Since the system bus permits broadcast signals by default, an
ordinary user can emit a spoofed PrinterSpooler signal despite the
comment claiming that only root can send it.

Deny signals on this interface in the default policy and allow them
again for root. This preserves reception for all connections and limits
the change to signal messages, avoiding an unintended restriction on
other message types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant