Hi Birger,
928032 is about IPCAllowedGroups. List/listen access on the IPC channel,
restricted by an IPCAccessControlFile. That is
not what I reported.
What I reported is debian/org.usbguard1.rules. Different file, different
channel (D-Bus), different authorization
decision. Not in 928032. Not in upstream. Debian-specific. The subject of this
bug is "plugdev gets full unauthenticated
control via D-Bus and IPC". You replied without mentioning D-Bus.
That polkit rule returns polkit.Result.YES for setParameter, appendRule, and
applyDevicePolicy for any active local user
in plugdev or sudo. No password. Upstream sets auth_admin on those three
actions in src/DBus/org.usbguard1.policy. The
Debian rule downgrades upstream's authorization model and ships it as the
default.
The postinst-generated IPCAccessControlFile restricts plugdev to policy=list,
devices=modify,list,listen, which
README.Debian correctly explains. The polkit rule routes around the ACL
entirely via D-Bus. The same package contradicts
itself: the IPC channel says plugdev is list-only, the D-Bus channel says
plugdev has full modify rights.
PoC from a plugdev user, no prompt:
busctl --system call org.usbguard1 /org/usbguard1/Devices \
org.usbguard.Devices1 applyDevicePolicy uuu <id> 0 0
Upstream's position is explicit. doc/usbguard-daemon.conf.5.adoc lines 123 to
125:
"Do not leave the ACL unconfigured as that will expose the IPC interface to
all local users and will allow them to
manipulate the authorization state of USB devices and modify the USBGuard
policy."
debian-installer (user-setup) adds the first non-root user, the only account
d-i forces an admin to create, to plugdev
automatically. Along with audio, video, cdrom, dialout, and the rest. No
prompt, no explanation. After apt install
usbguard, that user has unauthenticated applyDevicePolicy rights against the
daemon the admin just installed to enforce
policy. The admin is never told this at any point. So a vanilla Debian install
plus one apt command gives the first
account full daemon control with no password.
That is not "doesn't fit my use case". It is a privilege grant the admin never
agreed to, defaulting to a user the
installer forced them to create.
Separate defect. /etc/usbguard/rules.conf and
/etc/usbguard/IPCAccessControl.d/* are generated by postinst and are not
declared as conffiles. Admin edits to harden the IPC ACL silently regress on
any postinst rerun: reinstall, divert,
remove and install. If a future maintainer changes the usbguard add-user
arguments, that change propagates via routine
apt upgrade with no dpkg --conffile prompt. The package treats its own
load-bearing security configuration as ephemeral.
Patch: https://salsa.debian.org/birger/usbguard/-/merge_requests/6. It drops
the polkit rule and the IPCAllowedGroups
patch, and adds a debconf question with default empty so granting the privilege
becomes a deliberate, preseedable action
by the admin instead of a hidden default.
Pétur
> On 3 May 2026, at 14.38, Birger Schacht <[email protected]> wrote:
>
> Hi,
>
> On 5/1/26 3:16 AM, Pétur Ingi Egilsson wrote:
>> There are two independent defects in the Debian packaging of
>> usbguard. Either one alone is enough for any local user in the
>> plugdev group to get full unauthenticated control of the daemon,
>> defeating the point of installing the package.
> Quoting from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928032
>
> > Add `plugdev` to the IPCAllowedGroups setting. It's commonly the group
> > that is allowed to deal with pluggable devices, and it's not a big
> > compromise to allow them to decide what gets plugged in or not.
>
> So the users in the `plugdev` group don't "GET full unauthenticated control
> of the daemon", they "HAVE full unauthenticated control of the daemon" and
> that's on purpose. I'm happy to discuss changes in the default configuration
> of usbguard, though. But I'm not sure about the severity of the bug.
>
> cheers,
> Birger
