将根shell保留在分离的屏幕会话中运行是否安全？

我很好奇让根外壳程序在分离的屏幕会话中运行的安全性。我通常从不这样做。

除了我的非root用户帐户可能遭到破坏（密码泄露，ssh密钥遭到破坏等）的可能性之外，我是否还应该担心其他进入进入独立的，受密码保护的屏幕会话的向量，或者是否可以分离屏幕会议被认为是惰性的？

我认为这是一个安全问题，因为“除了我的非root用户帐户可能受到损害的可能性之外”，它可能会很大。

但是除此之外，还有其他增加的风险。例如，您现在已经接受了一种理论上的利用，可以利用它来更改屏幕套接字目录中的权限（/var/run/screen在我的系统上，但有时/tmp会使用）。现在，该漏洞利用已有了一条扎根的道路，否则可能就没有了。

sudo如果您可以训练自己将其用于每个命令而不是这样做，则它还有其他优点sudo su -。它记录操作（除非您进行远程登录，否则操作不会有意义地提高安全性，但会为您提供已完成操作的线索）。它通过要求每个命令有意上报，而不是切换到完全特权的会话，来帮助防止事故发生。

如果您在屏幕会话中具有根shell（无论是否已分离，是否具有密码保护），而您的screen可执行文件不是setxid，则获得您特权的攻击者可以在该shell中运行命令。如果没有别的，他们可以通过追踪屏幕过程来完成。

如果screen是setuid或setgid，并且会话是分离的并受密码保护，则原则上它需要使用屏幕密码来在该Shell中运行命令。如果这个原则成立，那么只会破坏您的帐户的人将不得不放置一个特洛伊木马，并等待您键入密码。但是，攻击面（即由于错误或配置错误而可能出错的地方的数量）太大。除了基本的系统安全功能，您还可以信任：

• 屏幕以正确检查密码。
• 屏幕以防止通过其他方式访问会话。
• 屏幕以正确使用操作系统访问控制机制（例如，管道权限）。
• 内核才能正确执行ptrace安全检查（这是漏洞的常见来源）。
• 正在运行的shell不会做任何愚蠢的事情。
• 其他一些功能不咬你。

“其他功能不咬你”：是的，这很模糊。但这始终是安全问题。您可能会认为这只是简单的一厢情愿的想法，但是您真的想到了一切吗？例如…

只要您可以写入终端设备，就可以将数据注入该Shell的输入中。在我的机器上屏幕的默认配置下：

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

这将插入␛]lfoobar␛l外壳程序的输入流。\ek是使应用程序（或可以写到终端设备的任何内容）设置窗口标题（请参阅屏幕手册中的“命名窗口”部分），\e[21t并使终端在应用程序的标准输入上报告其标题的控制序列。屏幕未记录此序列，但确实实现了该序列；您可以CSI Ps ; Ps ; Ps ; t在xterm控制序列列表下找到它，实际上，至少在屏幕4.0.3下，所有控制字符都从报告的标题中删除，因此shell读取lfoobar（假定␛]不与编辑命令绑定），也没有换行符，因此攻击者实际上无法以这种方式执行命令，但可以填充类似chmod u+s /bin/sh 其次是很多空格和可能看起来的提示。

屏幕还实现了其他几个类似的风险控制序列，我不知道它们潜在的漏洞是什么。但是希望到现在为止，您可以看到屏幕会话密码所提供的保护不是那么好。专用的安全工具（如sudo）极少有漏洞。

屏幕创建的管道仅可由所有者访问，因此这不是安全问题。