4 ms·

Not necessarily; it could simply connect to a tmux session.

by Seirdy 5y ago

vidarh 5y ago
In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...

Not necessarily; it could simply connect to a tmux session.

by Seirdy 5y ago

Not necessarily; it could simply connect to a tmux session.

In which case the terminal can use the tmux session to carry out its evil deeds. Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to. Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering. EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this: X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session] <---[rendering instructions]----/ <----[pty w/output]------------------/ The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side. You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that. It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...