6 ms·

All the applications getting keyup events seems like big security issue. Is this same case with Wayland

yw3410 5y ago
Is what the same as Wayland? Maybe you've misunderstood the article? The process is running as root and reading directly from /proc; the article acknowledges that it's essentially a keylogger.
- chaorace 5y ago
  I am now curious, though. How does Wayland handle key events? I have to imagine it only lets the active window listen in on key events, right? Maybe there's an API for subsribing to specific key combinations?
  - chrisseaton 5y ago
    > Maybe there's an API for subsribing to specific key combinations? Why would you ever let a non-focused application subscribe to any key combinations?
    - pjc50 5y ago
      https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... : for global hotkeys.
      - deleted 5y ago
        [deleted]
      - chrisseaton 5y ago
        That doesn't seem like something that an application should be getting involved with. An application should only be able to manage its own windows and key presses to its own window.
        R0b0t1 5y ago
        Problematic. Means you are relying on the DE for all UI development. With Windows and X11 the DE is reconfigurable to some extent by applications. There is also more to this, showing the Wayland security model is incoherent. If debugging is enabled on your system I can simply debug your root terminal and start injecting commands into memory.
        zxzax 5y ago
        Wayland obviously cannot solve all security issues and privilege escalations in the underlying OS -- the solution to that problem would be to just disable debugging within that security context. In Wayland the situation is also not so much different from Windows, you would just reconfigure and extend the DE itself. You are already relying on them to provide most of the UI to an extent.
        R0b0t1 5y ago
        In regards to your first point, I am saying that Wayland does not do what it sets out to do and the proper way of doing it is a much larger problem than what Wayland can address. It is possibly better to avoid breaking everyone's stuff if you're just going to need to shortly do it again to fix the things Wayland does not and can not fix. For your latter point, Wayland is much different. In Windows there are ways to inject behavior into other programs or the UI elements. This exists so you can change the UI. Wayland's idea of security is very much against that, at least in the way it can be done on Windows/X11.
        zxzax 5y ago
        I don't know what you mean you'll need to break it again, this one particular hole is already plugged in Wayland. That won't cause additional breakage, and you'll still want to be plugging those additional holes like ptrace anyway. Input injection is being worked on in a different library, that brings a standard API that's supposed to work the same across Wayland, X11, and with sandboxed contexts: https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
    - yjftsjthsd-h 5y ago
      In order to implement https://www.semicomplete.com/projects/keynav/ https://www.semicomplete.com/projects/keynav/ (or anything else that listens for a specific key combo to activate)
      - chrisseaton 5y ago
        Isn't that kind of thing the responsibility of the desktop environment service? Not an application?
        yjftsjthsd-h 5y ago
        I suppose the proper answer is that that very much depends on your philosophy of desktop environments; I happen to prefer modular desktops built out of separate programs from separate authors which may or may not even know about each other. This has the advantage of making it trivial to retrofit new features without needing to ask your DE upstream. Or to be more pithy: Okay, fine; what desktop environments implement keynav? With X11, I can make the answer be "(probably) all of them".
        riskable 5y ago
        As long as the desktop environment provides a mechanism for applications to register their global shortcuts then all is well. However, without such a feature the application has to just listen for all keystrokes and check if it matches something the user's configured. Example: I've bound several scenes in OBS to keyboard shortcuts so that I can switch scenes no matter what application I'm in. I'm pretty sure OBS does this by listening to all keyboard events on the root window. It's not very efficient, but it works. Now imagine having to support a global shortcut daemon per DE that exists. I suppose someone would write an abstraction but really, it's something that FreeDesktop.org should provide (if it already doesn't).
    - jeroenhd 5y ago
      WorkRave can't function well without it. Currently, it's working through a compatibility layer I think, but if that breaks, the application can't be made to work on Wayland AFAIK. Alternative shortcut managers might also run into trouble (say, clipboard managers with customizable shortcuts) although those could work with a simple permission prompt for each new shortcut. Very annoying and obtrusive to the user, but the security principles remain. There are also tools that extend some window managers with i3-like shortcuts and configurations; the config files are parsed on the fly and they need to work in the background. Then there's tools like AutoHotkey that can be great tools for productivity through scripting and custom shortcuts. A lot of AH's functionality can be replicated using the standard hotkey API, but not everything. There's also diagnostic tools (see Windows Steps Recorder) that record all keystrokes and generate a step by step report about what happened with screenshots as a guide. IMO global key capture should still be possible with the right capabilities set because there are valid use cases for it. Requiring additional permissions is fine IMO, but completely removing the option to do this is a pain.
    - joaonmatos 5y ago
      Global Hotkeys for something like Quake terminal, or voice chat push-to-talk. Obviously I don't see why you would encumber the core protocol for it, but a subscription model for it as a wlroots or FreeDesktop portal could be interesting.
    - reificator 5y ago
      > Why would you ever let a non-focused application subscribe to any key combinations? * Media playback controls * Hotkeys to take screnshots, or record videos * Quake style terminals * Ingame chat and game invites * Color pickers * Screen controls like F.lux * Window management hotkeys * Push-to-Talk in group voice calls And that's just what I personally use on my own machine. It's a massive security issue that any installed software can listen to any input activity or view/affect other windows, and that does need to be reigned in. But to claim that there's no legitimate utility to global hotkeys is absurd. We need robust permissions, not a completely crippled experience.
      - topaz0 5y ago
        In my experience most of these use cases are handled on linux by the window manager calling a script that sends a message to the relevant application, e.g. over dbus.
        reificator 5y ago
        Sure, and that works fine. Just let my application tell the window manager: * What key events I care about. (I.E. what the keybind should be named in the settings UI) * What script or message to pass back to me when that event is activated. * What the default keycombo should be, if any.
        michaelmrose 5y ago
        Some applications prefer to provide a ui for the user to configure a hotkey. This is naturally discoverable within the scope of the other settings in its preferences screen. Providing a cli interface for automation or binding a hotkey is imo more powerful and useful but its not discoverable. Doubly so for a controlling it over dbus. The logical thing is that since there is a substantial use case and a desire to limit applications access to global info is that a permission system ought to have been built into Wayland such that applications could request not only global access to the keyboard but permission to get a notification when a particular key press happened. Since this feature was a staple of desktop operating systems for decades it ought to have been part of the plan from the start.
    - pdkl95 5y ago
      I am currently writing a utility to spy on Super Hexagon's KeyPress/KeyRelease XEvents with the goal of recording very precise timestamps for each event. Since the walls in the game arrive at a constant rate, I want to graph my keypress/keyrelease events modulo the time between walls. My success rate for finishing Hyper Hexagonest[1] is falling; being able to inspect recent attempts might reveal where my timing is drifting. (it's only ~25%-ish finished, unfortunately) [1] https://www.youtube.com/watch?v=JJ96olZr8DE https://www.youtube.com/watch?v=JJ96olZr8DE
    - tjalfi 5y ago
      PureText[0] is a Windows application I use regularly. It adds a keyboard shortcut for pasting as plain text. [0] https://stevemiller.net/puretext/ https://stevemiller.net/puretext/
  - ashafer 5y ago
    iirc it's pretty much completely up to the compositor. The spec is worded to allow "focus" to enter a surface and deliver events to it, but it never specifies under what conditions the compositor should do so. So the compositor chooses what surface to deliver events to based on its own desires (like letting pointer focus enter background apps) and the users input. I think there is a protocol (used by Xwayland?) to allow a client to get events from any window if the compositor/user allows it
    - Cloudef 5y ago
      That's how it is. It's up to compositor to decide what events to send to what clients. Usually this means compositor only forwards input events to the focused surface.

Is what the same as Wayland? Maybe you've misunderstood the article? The process is running as root and reading directly from /proc; the article acknowledges that it's essentially a keylogger.

chaorace 5y ago
I am now curious, though. How does Wayland handle key events? I have to imagine it only lets the active window listen in on key events, right? Maybe there's an API for subsribing to specific key combinations?
- chrisseaton 5y ago
  > Maybe there's an API for subsribing to specific key combinations? Why would you ever let a non-focused application subscribe to any key combinations?
  - pjc50 5y ago
    https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... : for global hotkeys.
    - deleted 5y ago
      [deleted]
    - chrisseaton 5y ago
      That doesn't seem like something that an application should be getting involved with. An application should only be able to manage its own windows and key presses to its own window.
      - R0b0t1 5y ago
        Problematic. Means you are relying on the DE for all UI development. With Windows and X11 the DE is reconfigurable to some extent by applications. There is also more to this, showing the Wayland security model is incoherent. If debugging is enabled on your system I can simply debug your root terminal and start injecting commands into memory.
        zxzax 5y ago
        Wayland obviously cannot solve all security issues and privilege escalations in the underlying OS -- the solution to that problem would be to just disable debugging within that security context. In Wayland the situation is also not so much different from Windows, you would just reconfigure and extend the DE itself. You are already relying on them to provide most of the UI to an extent.
        R0b0t1 5y ago
        In regards to your first point, I am saying that Wayland does not do what it sets out to do and the proper way of doing it is a much larger problem than what Wayland can address. It is possibly better to avoid breaking everyone's stuff if you're just going to need to shortly do it again to fix the things Wayland does not and can not fix. For your latter point, Wayland is much different. In Windows there are ways to inject behavior into other programs or the UI elements. This exists so you can change the UI. Wayland's idea of security is very much against that, at least in the way it can be done on Windows/X11.
        zxzax 5y ago
        I don't know what you mean you'll need to break it again, this one particular hole is already plugged in Wayland. That won't cause additional breakage, and you'll still want to be plugging those additional holes like ptrace anyway. Input injection is being worked on in a different library, that brings a standard API that's supposed to work the same across Wayland, X11, and with sandboxed contexts: https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
  - yjftsjthsd-h 5y ago
    In order to implement https://www.semicomplete.com/projects/keynav/ https://www.semicomplete.com/projects/keynav/ (or anything else that listens for a specific key combo to activate)
    - chrisseaton 5y ago
      Isn't that kind of thing the responsibility of the desktop environment service? Not an application?
      - yjftsjthsd-h 5y ago
        I suppose the proper answer is that that very much depends on your philosophy of desktop environments; I happen to prefer modular desktops built out of separate programs from separate authors which may or may not even know about each other. This has the advantage of making it trivial to retrofit new features without needing to ask your DE upstream. Or to be more pithy: Okay, fine; what desktop environments implement keynav? With X11, I can make the answer be "(probably) all of them".
      - riskable 5y ago
        As long as the desktop environment provides a mechanism for applications to register their global shortcuts then all is well. However, without such a feature the application has to just listen for all keystrokes and check if it matches something the user's configured. Example: I've bound several scenes in OBS to keyboard shortcuts so that I can switch scenes no matter what application I'm in. I'm pretty sure OBS does this by listening to all keyboard events on the root window. It's not very efficient, but it works. Now imagine having to support a global shortcut daemon per DE that exists. I suppose someone would write an abstraction but really, it's something that FreeDesktop.org should provide (if it already doesn't).
  - jeroenhd 5y ago
    WorkRave can't function well without it. Currently, it's working through a compatibility layer I think, but if that breaks, the application can't be made to work on Wayland AFAIK. Alternative shortcut managers might also run into trouble (say, clipboard managers with customizable shortcuts) although those could work with a simple permission prompt for each new shortcut. Very annoying and obtrusive to the user, but the security principles remain. There are also tools that extend some window managers with i3-like shortcuts and configurations; the config files are parsed on the fly and they need to work in the background. Then there's tools like AutoHotkey that can be great tools for productivity through scripting and custom shortcuts. A lot of AH's functionality can be replicated using the standard hotkey API, but not everything. There's also diagnostic tools (see Windows Steps Recorder) that record all keystrokes and generate a step by step report about what happened with screenshots as a guide. IMO global key capture should still be possible with the right capabilities set because there are valid use cases for it. Requiring additional permissions is fine IMO, but completely removing the option to do this is a pain.
  - joaonmatos 5y ago
    Global Hotkeys for something like Quake terminal, or voice chat push-to-talk. Obviously I don't see why you would encumber the core protocol for it, but a subscription model for it as a wlroots or FreeDesktop portal could be interesting.
  - reificator 5y ago
    > Why would you ever let a non-focused application subscribe to any key combinations? * Media playback controls * Hotkeys to take screnshots, or record videos * Quake style terminals * Ingame chat and game invites * Color pickers * Screen controls like F.lux * Window management hotkeys * Push-to-Talk in group voice calls And that's just what I personally use on my own machine. It's a massive security issue that any installed software can listen to any input activity or view/affect other windows, and that does need to be reigned in. But to claim that there's no legitimate utility to global hotkeys is absurd. We need robust permissions, not a completely crippled experience.
    - topaz0 5y ago
      In my experience most of these use cases are handled on linux by the window manager calling a script that sends a message to the relevant application, e.g. over dbus.
      - reificator 5y ago
        Sure, and that works fine. Just let my application tell the window manager: * What key events I care about. (I.E. what the keybind should be named in the settings UI) * What script or message to pass back to me when that event is activated. * What the default keycombo should be, if any.
      - michaelmrose 5y ago
        Some applications prefer to provide a ui for the user to configure a hotkey. This is naturally discoverable within the scope of the other settings in its preferences screen. Providing a cli interface for automation or binding a hotkey is imo more powerful and useful but its not discoverable. Doubly so for a controlling it over dbus. The logical thing is that since there is a substantial use case and a desire to limit applications access to global info is that a permission system ought to have been built into Wayland such that applications could request not only global access to the keyboard but permission to get a notification when a particular key press happened. Since this feature was a staple of desktop operating systems for decades it ought to have been part of the plan from the start.
  - pdkl95 5y ago
    I am currently writing a utility to spy on Super Hexagon's KeyPress/KeyRelease XEvents with the goal of recording very precise timestamps for each event. Since the walls in the game arrive at a constant rate, I want to graph my keypress/keyrelease events modulo the time between walls. My success rate for finishing Hyper Hexagonest[1] is falling; being able to inspect recent attempts might reveal where my timing is drifting. (it's only ~25%-ish finished, unfortunately) [1] https://www.youtube.com/watch?v=JJ96olZr8DE https://www.youtube.com/watch?v=JJ96olZr8DE
  - tjalfi 5y ago
    PureText[0] is a Windows application I use regularly. It adds a keyboard shortcut for pasting as plain text. [0] https://stevemiller.net/puretext/ https://stevemiller.net/puretext/
- ashafer 5y ago
  iirc it's pretty much completely up to the compositor. The spec is worded to allow "focus" to enter a surface and deliver events to it, but it never specifies under what conditions the compositor should do so. So the compositor chooses what surface to deliver events to based on its own desires (like letting pointer focus enter background apps) and the users input. I think there is a protocol (used by Xwayland?) to allow a client to get events from any window if the compositor/user allows it
  - Cloudef 5y ago
    That's how it is. It's up to compositor to decide what events to send to what clients. Usually this means compositor only forwards input events to the focused surface.