Screen에 여러 사용자가 같이 세션에 접속할 수 있게 해주는 멀티 유저 모드가 있음, 이 기능 덕분에 tmate 같은 도구가 가능해진다고 생각함, tmux도 동일한 취약점이 있는지 궁금함
tmux는 유닉스 도메인 소켓을 사용함, 왜 screen이 setuid 방식을 썼는지 이해되지 않음, root 권한이 필요 없어 보임, TFA에 설명된 바에 따르면 현재 screen 개발자들이 코드베이스를 완전히 파악하지 못해 setuid-root 방식이 쉽게 기능을 구현할 수 있어서 선택한 걸로 보임
이 기능 정말 훌륭함, 트레이닝 세션에서 학생마다 내 노트북에 자신의 로그인 계정을 주고 ssh 셸을 'screen -x <특정 유저의 창>'으로 제한하여 학생이 해당 screen ACL에 허락된 윈도우만 쓸 수 있게 함, 나는 projector로 각 학생의 화면을 한 명씩 확인해 보여줌, 근데 보안 구멍 투성이라는 건 놀랍지 않음
screen -x 명령어를 쓴 경험 있음
Debian에서는 GNU screen이 setuid root 권한으로 설치되어 있지 않음
Debian Stable(bookworm) 패키지는 너무 오래되어 5.0.0 취약점에 영향 없음, 예전엔 Debian이 소프트웨어 버전이 너무 느림을 싫어했으나, 지금은 필요한 몇몇 응용프로그램만 따로 패키지 소스를 써서 신버전을 쓰고, 다른 것들은 구버전으로도 잘 사용 중임
Gentoo도 마찬가지임, 하지만 Gentoo에서는 utmp 그룹에 SETGID가 설정됨, 어떤 의미가 있는지는 잘 모름
얼마나 많은 개발자들이 인기있는 오픈소스 도구들을 전부 직접 써보는지, 그리고 그 도구들을 사용하는 분야에는 어느 정도의 돈이 오가는지 궁금함
tmux는 OpenBSD 기본에 4.6부터 들어갔던 걸로 기억하며, 감사를 거쳤음, 좀 더 보안을 신경 쓰는 사람들에게 좋은 대안임
screen이 언급된 걸 보고 과거에 tmux로 전환했다가 실수로 screen을 안 써서 헷갈렸던 기억이 남
screen과 setuid가 언급된 게 재미있음, 한 번은 이상한 이슈를 해결하려고 screen에 chmod u+s를 줬었음, 이런 걸 해야 한다는 게 기분이 이상했음, 하지만 알고보니 screen에는 setuid에 의존하는 기능이 있었고 어떤 시스템은 기본적으로 그렇게 배포된다는 걸 알게 됨, 그리고 u+s를 주니 screen이 내 ~/.screenrc 대신 root의 ~/.screenrc를 읽었음(임시방편으로 받아들임), screen의 build마다 setuid 지원이 다를 수도 있다고 생각함
setuid는 원래 그런 식으로 동작함, 바이너리에 특수 비트를 세팅하면 항상 제공된 user로 실행하라는 의미임