If I’m not mistaken, you can make rules per device ID. Keychron devices show up as a keyboard/mouse and a “Link” device. You could make a passthrough rule just for the Link, thus not granting access to the actual input device.

That’s great, just be sure your rules are specific enough for that device but didn’t rely on some randomness for detection. I.e. Matching on the current evdev or hidraw devnode is bad because it can shift with more devices being added, changing ports, or some randomness in enumeration speed. Instead, do an attribute walk on the devnode to find specific unique attributes for that node, such as VID + PID + subsystem + bInterfaceNunber should be unique. Things like names and phys patch aren’t guaranteed to be unique or consistent in different operating modes. You’ll also want to check the devnodes of the other interfaces to be sure they won’t match by doing a test.

The commands for those things are: udevadm info -a /path/to/devnode udevadm test /path/to/devnode

Could you elaborate on the OpenRGB thing? I’ve used it a few times but never paid attention to the rules it asks for

Sure. While not technically necessary for some devices, they have pretty open blanket udev rules. This is because most keyboard devices require the use of hid reports directly to the device to make changes.

From their page:

On Linux, OpenRGB needs permission to access the hardware interfaces used for RGB control. These include USB and I2C interfaces. To make accessing these interfaces easier, OpenRGB provides a udev rules file that tells your operating system to allow your user account control over these hardware interfaces, allowing OpenRGB to run without root access while still controlling the hardware.

Notice the complete lack of warning about any security issue from doing this.

If they wanted to be secure they could make a root level daemon that does all the hardware interfacing, and provide a dbus interface managed through polkit to allow making those changes from the userspace UI.