☰

Sudo 票证和后续的非 sudo 同级进程

tag-icon • tag-icon linux permissions security sudo root
Sudo 票证和后续的非 sudo 同级进程

想象一下，我的系统本地sudo配置了超时，这样一旦我sudo在某个终端中运行一次后进行身份验证，我就不需要在另外 10 分钟内重新进行身份验证。

这是否有效地使进程作为进程的子进程运行调用sudo，但不使用sudo它们自己一起调用（因此作为兄弟姐妹，而不是孩子所运行的进程的和 sudo）能够将权限升级为 root 吗？

作为一个具体的例子，假设我在终端中运行：

sudo echo "hi"
other_process

该echo进程使用 运行sudo，但other_process不是。可以other_process使用与先前调用关联的 10 分钟到期 sudo 票证sudo，例如，通过 ? 本身启动子流程sudo？

我想如果答案是肯定的，则意味着您需要非常小心在超时期限内运行的任何进程sudo。人们可能会想象，运行一个不受信任的进程，就像other_process将其保留在当前用户的沙箱中一样，但如果它可以使用现有的sudo票证，它就可以升级为 root。

sudo如果调用不是直接在终端中而是在从终端启动的脚本中进行，答案是否会改变？

例如，我运行：

script.sh
other_process2

如果里面script.sh有这样一行sudo echo "inside script"，那么脚本随后启动的其他进程是否能够使用 sudo 票证将其权限提升到 root？脚本完成后怎么样：运行的终端中的其他进程script.sh仍然可以使用sudo票证1吗？

1这些不再像兄弟进程，而是某种程度上的“阿姨”或“叔叔”进程（父进程的兄弟姐妹）。

答案1

是的，sudo 票证适用于该终端中运行的任何进程（至少以您的用户身份运行）。这很容易测试。只需制作一个test.sh（或其他）：

#!/bin/sh

sudo apt-get check

然后：

$ sudo apt-get check
[sudo] password for anthony: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done

$ ./test.sh 
Reading package lists... Done
Building dependency tree       
Reading state information... Done

一般来说，不建议运行不受信任的程序，尤其是作为您的用户。而且您当然不应该在拥有 sudo 票证的终端上执行此操作。如果必须运行不受信任的程序，则应该设置安全屏障（至少是不同的用户，但更好的是虚拟机，或者至少是容器 - 为运行不受信任的程序设置安全沙箱并非易事）。

答案2

是的。由于sudo授权与您的用户名、tty 和时间戳的组合相关联，因此从该 shell 运行的任何命令都可以通过 sudo 传递自身提升权限的能力，而无需输入密码（假设您timestamp_timeout=0的文件中没有密码/etc/sudoers）。

只要这些脚本在您设置的超时（默认 = 15 分钟）内执行即可。

文件测试.sh：

#!/bin/bash

echo "test: \$SHLVL is: $SHLVL"
echo "test: I am $(id) on $(tty)"
echo "test: with sudo I am $(sudo id) on $(tty)"
/bin/bash -l ./sudotest.sh

文件sudotest.sh：

#!/bin/bash

echo "sudotest: \$SHLVL is: $SHLVL"
echo "sudotest: I am $(id) on $(tty)"
echo "sudotest: with sudo I am $(sudo id) on $(tty)"

结果是：

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
[sudo] password for tim:
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

在这种情况下，对 sudo 的第一次调用是在test.sh，但是sudotest.sh是不是使用 sudo 本身调用，但是因为我的用户名和 tty 仍然相同，所以 sudo 认为该进程有资格获得提升的权限，并且在执行sudotest.sh.

如果我在几分钟后但在超时之前再次运行它：

test: $SHLVL is: 2
test: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
test: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7
sudotest: $SHLVL is: 3
sudotest: I am uid=1000(tim) gid=1000(tim) groups=1000(tim) on /dev/pts/7
sudotest: with sudo I am uid=0(root) gid=0(root) groups=0(root) on /dev/pts/7

我根本没有得到提示。在时间限制过去之前我不会timestamp_timeout。

您可以看到 tty 在整个执行过程中保持不变，并且该值SHLVL正在递增，因为脚本执行的每个 shell 进程都比调用 shell 更深一层。我的交互式 shellSHLVL = 1调用test.shwhich gets SHLVL = 2，which 调用sudotest.shwhich gets SHLVL = 3。

一个可能的警告是，如果您有旧版本的 sudo，其中tty_tickets未设置该选项，这会删除 sudo 会话的用户名+tty 粒度，并将粒度仅限于用户名和时间戳。

其他sudoers选项也可能产生影响，例如requiretty.

只要sudo在 sudo 凭据保留的时间限制内发出对原始 shell 调用的脚本的后续调用，他们就能够以同一用户的身份进行提升。一旦时间限制结束，如果您希望他们能够继续提升权限，他们将需要有办法重新输入密码。 （或者您可以更改超时，或禁用用户或命令的密码要求......但这些超出了本答案的范围）。

答案3

答案是不。尝试sudo id随后id进行验证。

相关内容