Hello Jared and Hanno! On Sat, Feb 08, 2025 at 07:18:22AM -0800, Jared Finder wrote: > Hi, I'm the original reporter of this regression (noticed because it > impacted GNU Emacs) and I'm wondering if there's any traction on creating an > updated patch? This thread appears to have stalled out. I haven't seen any > reply for three weeks. > > -- MJF Jared, can you please confirm whether Emacs works now with this patch in the kernel? I am asking this because I realized that the patch had a bug. We are erring in the "secure" direction, but not all TIOCL_SELMOUSEREPORT invocations work without CAP_SYS_ADMIN. (TIOCL_SELMOUSEREPORT has to be put into the sel_mode field of the argument struct, and that field looked like an enum to me, but as it turns out, the TIOCL_SELMOUSEREPORT is 16 and the lower 4 bits of that integer are used as an additional argument to indicate the mouse button status and modifier keys. I had overlooked that the implementation was doing this. As a result, TIOCL_SELMOUSEREPORT works without CAP_SYS_ADMIN, but only if all four lower bits are 0.) So, I apologize for the oversight. -- Jared, can you please confirm whether TIOCL_SELMOUSEREPORT is called directly from Emacs (rather than from gpm)? I tried to trace it with perf but could not reproduce a scenario where Emacs called it. If this specific selection mode is not needed by Emacs, I think *the best thing would be to keep it guarded by CAP_SYS_ADMIN, after all*. As it turns out, the following scenario is possible: * A root shell invokes malicious program P and changes its UID to a less privileged user, but it passes a FD to the TTY. (Instead of UID switch, it can also be a sandboxed program or another way of lowering privileges.) * Program P enables mouse tracking mode by writing "\033[?1000h". * Program P sends IOCTL TIOCLINUX with TIOCL_SETSEL with TIOCL_SELMOUSEREPORT and passes suitable mouse coordinate and button press arguments. As a response, the terminal writes the escape sequence \033[MBXY, where B, X and Y are bytes indicating the button press mask and the 1-based mouse X and Y coordinates, all added to 0x20 (space). It is an obscure scenario and probably requires a console with a character width and height above 256 (to control the full byte range), but it seems that this can in principle be used to simulate short keyboard inputs to programs (like bash) that are not expecting this old mouse protocol. - This sort of keypress-simulation is exactly why we created the CAP_SYS_ADMIN restriction for TIOCL_SETSEL in the first place. For background on this mouse tracking mechanism, I had to read up on it myself, but found the following two links helpful: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Normal-tracking-mode https://www.ibm.com/docs/en/aix/7.2?topic=x-xterm-command#xterm__mouse (Remark on the side, the GPM client library normally gets its mouse coordinates through a Unix Domain socket from the GPM daemon. It has support for this xterm emulation mode as well, but it is only enabled if $TERM starts with "xterm".) In summary: If it is not absolutely needed, I think it would be better to not permit access to TIOCL_SELMOUSEREPORT after all. It does not let attackers simulate keypresses quite as easily as the other features, but it does let them send such input with more limited control, and it seems like an unnecessary risk if the feature is not needed by anything but mouse daemons running as root, such as GPM and Consolation. Does this seem reasonable? (Hanno, do you agree with this assessment?) I am by no means an expert in this terminal-mouse interaction, I am happy to stand corrected if I am wrong here. –Günther
