My `~/.screenrc` has a comment at the top, which says I created it on "05-May-1994" (before I switched to ISO 8601 dates).
I'm no longer using `screen` on an HP 2392A dumb terminal and PP 14.4kbps modem. But `screen` is still coming in very handy, when working on servers, and for some kinds of developing&running long-running programs on the workstation laptop.
It's also fun, on the occasion that you introduce `screen` or `tmux` to programmers who've been using lesser tools, and they become an instant convert.
Incidentally, given how old the code is, and how there's the potential for various kinds of remote exploits via text (e.g., in SSH session, or in display of user-crafted strings in a console program), I wonder how recently someone has done a rigorous security audit of `screen`.
Related/funny: three years ago, someone found exactly such a bug because it was exploited against a Minecraft server they were running in screen (probably without the perpetrator understanding the root cause): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0...
I just checked my .screenrc and while I don't have a date in it, the file was last modified in 2010. But that's around the time that I switched to tmux. I've been _very_ happy with tmux over the years…
Looking over the screen 5 release notes it's hard to tell what I've missed being out of that world over the past 15 years. Does anyone have a good rundown on their current differences?
There are bugs. But Screen itself is running locally and per-user?
I could imagine attacking from one tab (window) interacting with another tab but then the user runs already a harmful application. I worry more about everything containing Electron or similar built “web applications”.
For example, you start a `screen` session, and within one of those `screen` windows, you SSH to an untrusted remote system, and that remote system can then send arbitrary bytes to be interpreted by `screen`. If there's a bug, it's potentially remote system having arbitrary code execution capability on your local system that's running `screen`, under your UID, and then escalate from there.
This is why Linux should be taking things like the xz exploit more seriously and, at least, adopting a solution like firejail or bwrap everywhere.
It's not a perfect solution, but it's a step in the right direction towards patching the Unix model, so that programs don't have privileges they don't need.
Mobile Linux (Mer / SailfishOS) works this way to mimic app-based architectures. But, unlike Android, it still feels like regular Linux.
`screen` is trickier to sandbox/compartmentalize than some programs, because it needs permission to create and interact with ttys, most often with shells attached to them, and normally those shells can't be restricted.
I used to do training with this. Every student got a private username/password to connect to my laptop where their login shell connected to a specific window (to which only that user had access) in a shared screen session. They each had their own little environment to hack in. Then when we were doing exercises and people got stuck, I would put their screen up on the projector so we could discuss their code together.
I'm no longer using `screen` on an HP 2392A dumb terminal and PP 14.4kbps modem. But `screen` is still coming in very handy, when working on servers, and for some kinds of developing&running long-running programs on the workstation laptop.
It's also fun, on the occasion that you introduce `screen` or `tmux` to programmers who've been using lesser tools, and they become an instant convert.
Incidentally, given how old the code is, and how there's the potential for various kinds of remote exploits via text (e.g., in SSH session, or in display of user-crafted strings in a console program), I wonder how recently someone has done a rigorous security audit of `screen`.