PPP 安全性和那些令人头疼的只运行脚本

问题：应该允许谁来发起 PPP 连接？

如果你检查 PPP 工具的权限，答案充其量是令人困惑的。启动连接涉及四个组件：两个脚本（ppp-on 和 ppp-on-dialer）和两个程序（pppd 和 chat）。按照 PPP 工具安装过程的设置（注意：通过其他发行版获得的 PPP 工具的权限假设会有所不同），这四个文件具有以下权限：

• ppp-on 可由 root 读取，并可由所有人执行；有限的读取权限保护脚本中包含的密码，同时理论上允许任何人运行。（用于关闭连接的 ppp-off 脚本具有相同的权限。）
• pppd 由 ppp-on 调用，设置为 setuid root，允许任何用户访问串口。
• ppp-on-dialer 由 pppd 使用实际用户的权限调用，仅可由 root 进行读写执行——对于一个不包含任何秘密，并且执行任何用户都可以执行的操作（运行 chat）的文件来说，这是非常奇怪的权限。
• chat 由 ppp-on-dialer 调用，具有正常的执行权限。

非特权用户启动 PPP 连接存在两个障碍：

1. ppp-on-dialer 脚本的权限受到限制。
2. 只运行程序可以工作，但只运行脚本（例如 ppp-on）则不行。

后一个限制是 UNIX 的一项安全功能：您有权执行该脚本，但无权将其读入解释器。如果您尝试“按原样”使用这些工具，则确实必须是 root 才能启动 PPP。或者，您可以遵循 Phil Hughes 在 1997 年 5 月 LJ 专栏中的建议，编写一个特殊的 setuid 程序来启动和停止 PPP。

我已经决定在我的系统上（我承认，我确实是唯一的用户）非特权用户可以启动 PPP 连接。该策略通过对这些工具进行一项更改（使 ppp-on-dialer 可供所有人读取/运行）和一个 hack：rscript 来实现。

rscript 工具是一个 setuid-root 程序，用于解决只运行脚本的问题；它以特权用户身份打开脚本，然后以实际用户身份解释它。调用

rscript

• 解释器能够通过 stdin 接受脚本输入，同时识别位置参数。例如，Bourne 风格的 shell 可以按以下方式调用：sh -s a b c通过 stdin 接受脚本输入并传递a, b和c作为脚本的位置参数。这样做的语法在不同的解释器之间有所不同，因此 rscript 使用解释器的基本名称和表中的信息来构造正确的命令行。
• 该脚本不得期望从 stdin 获得任何输入，因为该通道已用于其他目的。

尽管存在限制，但 rscript 与 PPP 脚本结合使用仍然非常有用。

rscript 是否是一个安全漏洞？除非用户能够替换执行脚本的解释器，否则 rscript 似乎不允许用户访问脚本的内容或执行任何特权操作。（如果我错了，我相信我会听到的。）