Hotkeys without the input group: pick the portal backend automatically

[guelz]

Hi Ron, thanks for TuxTalk. I use it every day on two KDE Plasma 6.7 Wayland machines.

The problem
For F8/F9 the AppImage needs my user in the input group. That lets every process I run read every keyboard, sudo passwords included, so I'd rather not have it on my workstations.

I know the Flatpak solves this with the GlobalShortcuts portal, but it's on hold. And PortalInputBackend is already in the code; get_input_backend() just only picks it when FLATPAK_ID is set.

Idea: no new option, just pick it automatically
Like the Swiss spelling from #10, which switches itself on for Swiss German systems:

• if the user can't read /dev/input and the desktop's portal offers GlobalShortcuts → use the portal (press and release, so hold-to-talk keeps working);
• otherwise → evdev, exactly as today.

People who already set up the input group wouldn't notice any change. Everyone else would get working hotkeys without adding a keylogger permission.

What I think makes it harder than it looks (please correct me):

• Outside a sandbox the portal doesn't know the app id. Newer xdg-desktop-portal versions have org.freedesktop.host.portal.Registry.Register for that.
• The key is assigned in the desktop's own shortcut dialog, so the hotkey test would need to work differently.
• XFCE, Cinnamon and MATE don't have the portal, so evdev stays as the fallback there.

Smaller alternative
A supported tuxtalk --toggle: start the service if needed, then toggle once it's ready. I bound F9 in KDE to a script that does this over D-Bus. It broke with the rename because it matched talktype.app, and it has to guess when the model is loaded, because toggles sent while it loads are dropped. A supported command would avoid both, at least for toggle mode.

Happy to test on KDE.

And thanks for catering to our Swiss peculiarities, by the way ;-)

[ronb1964]

Hi guelz, good to hear from you again, and glad it's earning its keep on both machines. You're right about the input group, and funny timing, I was just going over this again myself. Being in that group means anything you run can read every keyboard, sudo password included. One thing your post didn't cover. Typing goes through /dev/uinput, and the udev rule TuxTalk installs hands that to the input group too, so moving just the hotkey to GlobalShortcuts wouldn't get anyone out of the group. I tried the portals outside the Flatpak on KDE 6.7 and GNOME 50 and they work, but you get KDE's "control input devices" prompt, GNOME's orange icon the whole time, the key picked in the desktop's own dialog, typing stuck on a US keymap, and nothing for XFCE, Cinnamon or MATE. So I went another way. TuxTalk gets a small helper that runs as a system service and is the only thing that reads the keyboards. It runs under systemd's DynamicUser with just the input group, no network, no home, no capabilities and a syscall filter, and systemd-analyze security rates it 0.6. It reports F1 to F24, Esc, Pause and Scroll Lock, and any other key only when two of Ctrl, Alt and Super are held with it. Never a letter, a number or Shift+letter, and only to logind's active user on seat0. For typing, /dev/uinput goes to whoever's at the screen through uaccess, same rule Steam ships. Programs can still type like now, but nothing can read keys. Setup is still one password prompt and the restart goes away. Where there's no systemd it falls back to the group. Your current setup keeps working, and Preferences offers to switch you over and take you out of the group. I had it reviewed twice before telling you, and the first review found a real hole. A program running as you could make a virtual keyboard, get the helper's grab going, hold Ctrl+Alt there where the desktop couldn't see it, and every key typed on the real keyboard came out as a Ctrl+Alt shortcut. I reproduced it in a VM and it read the word I typed. Now modifiers only count if the desktop saw them go down, a virtual keyboard can't lend its modifiers to a real one, AltGr never counts, and the grab only covers the keyboard the hotkey came from. Same test against the fixed one gets nothing. Then I had Codex go over it too, as a third set of eyes. It didn't find a way to read typing either. It did find that a program holding F8 on its own virtual keyboard could block the real F8, and that a failed ungrab could leave the keyboard held with nothing left to let it go. Both are fixed, that's helper 1.3. Dictation works with my user out of the input group on CachyOS KDE, Ubuntu 26.04 GNOME and Fedora 44 KDE with SELinux enforcing, and the key reporting checks out on Mint 22.3 on X11. One thing changes: a shortcut that isn't an F-key needs two of Ctrl, Alt and Super. Thing is, any single modifier can be turned into AltGr by an XKB option. The defaults are Ctrl+Alt so they're fine. I built your --toggle too, with --start and --stop. It waits for the service to say it's ready instead of guessing, and if nothing's running it starts TuxTalk first. It'll be in 0.15.1. Sorry the rename broke your script. And thanks for all your help, here and back on #7 and #8. I'm still a novice at a lot of this, so forgive me if I mess up a few things along the way. I really do value your input. If you're up for it, both are on the secure-hotkeys branch now (git clone -b secure-hotkeys https://github.com/ronb1964/TuxTalk). Run it from source, then Preferences, Advanced, Typing Setup has Switch to Hotkey Helper. That's the one password and it takes you out of the input group in the same go. The README's troubleshooting section has the two commands to take the helper off again if you want it gone. I'd love to hear how it does on your KDE machines before it goes into a release. Ron -- Regards, *Ron Brand*

[ronb1964]

--toggle is out in 0.15.1. If you installed from the .deb, .rpm or the AUR it's just tuxtalk --toggle, and with the AppImage you run the AppImage file with --toggle after it. --start and --stop work the same way.

If TuxTalk isn't running yet, it starts it, and if the model is still loading, the recording starts the moment it's ready, so a press right after login doesn't get lost. You should be able to point your KDE shortcut straight at it and drop the D-Bus script.

The hotkey helper is still on the secure-hotkeys branch, and it'll go into 0.16. If you get a chance to try it on your KDE machines before then, I'd really like to hear how it goes.

[guelz]

Hi Ron
I've merged secure-hotkeys into type-at-pause-fixes locally and tested it on three different PCs . All KDE Plasma though. F8 hold and F9 toggle both work without the input group. It seems to work just fine. I've also run it through another Claude security review, and the clanker says it's fine too! I'm pasting the full output below:

1. Verdict
He can keep it installed on his single-user desktop. It is clearly better than the input group: I found no path in the code by which a program running as him can read letters, digits, Enter or Shift+letter. The one real new power is the uinput uaccess rule, which lets every program he runs type into any window, including the lock screen. That is inherent to the design, not a bug. Nothing needs doing now, except to treat any unexpected "run /bin/bash as root" password prompt as hostile.

2. Claims check

• Sandboxed service (DynamicUser, input group only, no network, empty capabilities, syscall filter): holds (secure_input.py:49-101). It needs write access to keyboards (DeviceAllow=char-input rw) for hiding a held key.
• Only F1–F24, Esc, Pause and Scroll Lock alone; anything else needs two of Ctrl/Alt/Super: holds (hotkey_helper.py:181-190, 534-539). Each report also carries the Shift/AltGr state at that moment (545).
• Only logind's active user on seat0, via SO_PEERCRED: holds, but per user id, not per session. It is checked on connect (646), on every report (522) and on hide (550). A hide ends at most about 0.5 s after a user switch (626).
• Only seat0 keyboards: holds (217-226, 271). The seat label can only be set by root's udev rules or a password-protected logind action.
• Install via pkexec with the script on stdin: holds (secure_input.py:269; quoted heredocs; mktemp then mv; symlink check at 138).
• python3 -I -S with standard library only: holds.
• Virtual keyboards can't lend modifiers: holds. Devices are grouped by the kernel's sysfs path (229-237, 449-455, 520).
• Modifiers count only if the desktop saw them go down: partly. The code approximates this as "the helper wasn't holding that keyboard at the time" (480-481). Modifiers already down at open, or after lost events, stay untrusted (252, 440). Good enough in practice.
• AltGr never counts: holds (113-118).
• The grab covers only the keyboard the hotkey came from: partly. It also grabs other real keyboards that hold a modifier reported with the press (578-596).
• A program holding F8 can't block the real F8 (the Codex finding): holds (444-447, 531-533). The limit of 8 virtual keyboards holds (157, 410-416).
• Log lines can't be forged through device names: holds (names are logged with !r).

3. Findings (none Critical or High verified)

Medium

1. A client may watch the whole keyboard. It can watch 32 keys (MAX_SPECS, 152, 712-727).
   • Scenario: something holds Ctrl+Alt on a real keyboard device while a client watches CA plus every letter. The user types into a password prompt that shows nothing (sudo or ssh in a terminal), and every key is reported.
   • Root cause: the rule only guarantees "the desktop sees a shortcut", not "the user isn't typing a secret".
   • A second case: in a Windows VM or RDP session, Ctrl+Alt means AltGr, so @ # € | typed that way are real text.
   • Status: conditional. It needs write access to a real keyboard device node, for example a keyboard-like device with a uaccess ACL. His machine has none.
   • Fix: allow at most about 4 combos per client (TuxTalk needs 2). Report at most 1–2 different combo keys per modifier hold. Never treat a device that udev tagged uaccess as real (G:uaccess in /run/udev/data).
2. The uaccess rule on /dev/uinput (secure_input.py:42-47).
   • Every program he runs can create keyboards and type into any window. That includes the lock screen and greeter, and other users' sessions after a switch, because an already-open uinput handle survives logind removing the ACL.
   • A Flatpak app with --device=all could type into a host terminal.
   • This is less than the input group gave (no reading), but more than no group at all.
   • Fix: document it, and offer a mode where only TuxTalk's typing path can reach uinput.

Low
3. Connections from other users are accepted one per loop pass. The socket is open to every user (381), the queue holds 8 (382), and one connection is accepted per loop pass (783). Another local user or service can keep the queue full and lock TuxTalk out. Fix: keep accepting until EAGAIN and enlarge the queue.
4. Eviction drops the oldest connection (656), which is usually TuxTalk. Any program of the same user can keep kicking it off; such programs could kill TuxTalk anyway, so this is mainly robustness. Fix: evict the newest connection instead.
5. Any client can hide on any F-key or Esc press (549-602, 633). The keyboard is then held until release plus 1 s, and keys typed in that second are lost, not leaked. A rival client can also take the hide before TuxTalk does. Fix: allow hiding only for the dictation keys (not Esc), one client at a time.
6. Race in tracking injected events (457-469, 581-594).

• If the key comes up just before the helper's own "release" is injected, the kernel drops that release.
• The leftover record then swallows the real release.
• Result: the keyboard stays held until the key is pressed again, UNHIDE, or 15 minutes pass. The window is tiny.
• Fix: after grabbing, re-check the kernel key state (EVIOCGKEY) and clear stale records.

7. Bluetooth keyboards may count as virtual (speculative: depends on BlueZ handling them in userspace, which puts them under /sys/devices/virtual). Their modifiers then don't pool with USB keyboards. Eight program-made keyboards can push one out, and that rejection is cached (414). Fix: classify by bus as well, keep room for physical keyboards, and don't cache "too many".
8. The install prompt is generic.
   • The polkit dialog says "run /bin/bash as root", which any malware can show identically.
   • The script is built from TuxTalk's own Python files (106-110), which may be user-writable. So "stdin, never a file" only protects the moment the dialog is open.
   • needs_update asks for the password whenever the versions differ (252-256).
   • Fix: a dedicated polkit action with a fixed, root-owned installer, or distro packages.
9. Minor issues.
   • Releases still go to clients no longer at the screen (490-504); harmless.
   • There is no CPU limit, so up to 8 flooding virtual keyboards can load the Python loop.
   • A keyboard with a touchpad on the same device node is ignored (270); functional only.

4. Residual risks inherent to the design

• Any program he runs sees the press/release timing of F-keys, Esc and allowed combos, with the Shift state, and can hide those keys.
• Keystroke injection through uinput.
• The rule assumes Linux desktop key meanings; Windows guests and unusual keyboard layouts can break that assumption.
• A compromised helper (small attack surface) could read and inject on every keyboard.

5. Feedback for the maintainer

• Allow at most about 4 combos per client, and at most 1–2 different combo keys per modifier hold.
• Treat uaccess-tagged devices as not real.
• Allow hiding only for the dictation keys, one client at a time, and end it right on release.
• Keep accepting connections until EAGAIN, and evict the newest connection rather than the oldest.
• After grabbing, re-check the kernel key state and clear stale injected-event records.
• Classify devices by bus too (Bluetooth via uhid), keep room for physical keyboards, and don't cache "too many".
• Correct the docs: the check is per user id, and a hide can also grab other keyboards holding a reported modifier.
• Document the uinput injection power (lock screen, other sessions, Flatpaks with device access), and replace pkexec /bin/bash with a polkit action.

Thank you so much for starting this! You wouldn't know for how many years I've been waiting for this to work on my local machine!-)

[ronb1964]

Hi Philipp,

Thanks for running it on three machines, and for the review. That's more testing than I could do myself.

I went through your list and helper 1.4 has almost all of it. Two different shortcut keys at most while Ctrl and Alt are held, four combos per client, keyboards with a uaccess tag kept apart from the real ones, Bluetooth keyboards counted as real while /dev/uhid is root only, accept until EAGAIN and evict the newest, Esc can't be hidden and the grab ends right on release. The race where a key comes up just before the grab is fixed with monotonic timestamps, and I checked that one on a real keyboard. The service has CPU and memory limits now too, and it won't ask for a password to "update" to an older helper.

The README spells out what uinput can do now, lock screen included, and that the check is per user.

The one I didn't do is the polkit action. Problem is it needs a root-owned installer there first, so it really belongs in the .deb and .rpm, and I'd rather do that properly than halfway.

Funny thing, your review turned something up on my own machine. OpenRGB's udev rule gives uaccess to every Logitech device, my K800 keyboard included, so anything I run could read it directly. Might be worth a look if you have OpenRGB installed.

It's all on main here and goes out in 0.16.

Ron