20 ms·

Nice write-up. > Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). T

by RMPR 1y ago

Nice write-up. > Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.

trollied 1y ago
Yup, screen -x
- qwertox 1y ago
  The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.
  - trollied 1y ago
    I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
    - radlad 1y ago
      I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
      - esseph 1y ago
        Often for long running jobs you want to see the status of where logging out of the system stops the job output.
        qwertox 1y ago
        Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
        esseph 1y ago
        System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
        ycombobreaker 1y ago
        The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
        throwaway173738 1y ago
        A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
        ycombobreaker 1y ago
        Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
        esseph 1y ago
        You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console. That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
      - magicalhippo 1y ago
        I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it. Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such. So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.
dooglius 1y ago
No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges. EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.
- JdeBP 1y ago
  screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10: https://sources.vsta.org/comp.sources.unix/volume10/screen/ https://sources.vsta.org/comp.sources.unix/volume10/screen/
  - ngangaga 1y ago
    [flagged]
    - 90s_dev 1y ago
      Nostalgia and novelty are powerful narcotics.
    - entropie 1y ago
      For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
      - noosphr 1y ago
        Screens main use case is to open an emacs session remotely. Tmux's main use case is to be glue for a unix IDE. The two use cases are rather different and the tools are very specialized for them.
        1y ago
thanatos519 1y ago
It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done. Not surprised to hear it's full of security holes. :)
- cess11 1y ago
  You can get close to the same experience with tmux. https://superuser.com/questions/188501/is-there-a-way-to-have-shared-control-tmux-session https://superuser.com/questions/188501/is-there-a-way-to-hav... Use groups instead of chmod 777.
deleted 1y ago
[deleted]

by RMPR 1y ago

trollied 1y ago

Yup, screen -x

qwertox 1y ago
The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.
- trollied 1y ago
  I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
  - radlad 1y ago
    I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
    - esseph 1y ago
      Often for long running jobs you want to see the status of where logging out of the system stops the job output.
      - qwertox 1y ago
        Or where you can't risk dropping the terminal session, like during a system upgrade via SSH.
        esseph 1y ago
        System upgrade shouldn't drop your session btw, at least not on most flavors I'm familiar with
        ycombobreaker 1y ago
        The risk is anything else dropping your connection while an interactive long-running process is going. You can nohup, or run inside something like screen/tmux,
        throwaway173738 1y ago
        A thoughtfully designed upgrade system doesn’t do the real work side your terminal session in the interactive process.
        ycombobreaker 1y ago
        Defense in depth is always valuable. The point of this thread is that screen protects your workflow from an unexpected disconnection.
        esseph 1y ago
        You're not wrong, but largely in the virtualized world we live in, it matters less and less when you have a virtual console. That said the sshd session you are connected on is still running the old executable until the service is restarted AND your session ends, so even if sshd gets upgraded, you should still be good to go.
    - magicalhippo 1y ago
      I use screen almost by default when connecting over SSH, but I've never used -x and didn't know about it. Habbit from back in the dial-up days when connections got dropped quite frequently. Still relevant with laptop going into sleep mode and such. So nice to just resume wherever you were as of nothing happened. Or to run jobs in the background, like long compiles, without an additional SSH session.

dooglius 1y ago

No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges. EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.

JdeBP 1y ago
screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10: https://sources.vsta.org/comp.sources.unix/volume10/screen/ https://sources.vsta.org/comp.sources.unix/volume10/screen/
- ngangaga 1y ago
  [flagged]
  - 90s_dev 1y ago
    Nostalgia and novelty are powerful narcotics.
  - entropie 1y ago
    For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
    - noosphr 1y ago
      Screens main use case is to open an emacs session remotely. Tmux's main use case is to be glue for a unix IDE. The two use cases are rather different and the tools are very specialized for them.
      - 1y ago

thanatos519 1y ago

It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done. Not surprised to hear it's full of security holes. :)

cess11 1y ago
You can get close to the same experience with tmux. https://superuser.com/questions/188501/is-there-a-way-to-have-shared-control-tmux-session https://superuser.com/questions/188501/is-there-a-way-to-hav... Use groups instead of chmod 777.

deleted 1y ago

[deleted]