在 Linux 中，可执行文件的位置会影响 setuid 位的解释方式吗？答案

【问题标题】：In Linux, does the location of an executable affect how the setuid bit is interpreted?在 Linux 中，可执行文件的位置会影响 setuid 位的解释方式吗？
【发布时间】：2013-02-28 21:41:09
【问题描述】：

在Linux系统中，setuid程序所在目录的权限是否会影响内核启动进程的方式？我问的原因是，当我在两个不同的目录中编译相同的 setuid 程序时，它实际上只假定了一个目录中的用户权限。我在/tmp 和/home/flag03 中编译了它，其中flag03 是我试图访问的用户帐户。从/tmp 执行时，它没有按预期提升权限，但它在/home 下工作。

问题的一些背景：

我正在处理exploit-exercises.com/nebula 的第 3 级。该练习要求您访问flag03 用户帐户。设置该练习，以便flag03 用户定期运行一个 cronjob，这将允许您在特定目录中执行脚本。我的计划是编写一个简单的 bash 脚本，该脚本将编译一个 setuid 程序，该程序本身会启动一个 bash shell，然后使用chmod +s 设置 setuid 位。这个想法是，当setuid程序被编译时，它是由用户flag03通过cronjob编译的。一旦执行了这个新编译的程序，它将以用户flag03 启动一个shell，这就是目标。

这是简单的 setuid 程序（l3.c，基于级别 1 + 2）：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int main(int argc, char **argv, char **envp)
{
  uid_t uid;
  gid_t gid;

  uid = geteuid();
  gid = getegid();

  setresuid(uid,uid,uid);
  setresgid(gid,gid,gid);
  printf("uid: %d\n", getuid());
  printf("gid: %d\n", getgid());
  system("/bin/bash");

  return 0;
}

为了使其工作，bash 脚本将程序编译为用户 flag03，然后对 setuid 位进行 chmod。

#!/bin/bash

#gcc -o /tmp/l3 /tmp/l3.c
#chmod +s,a+rwx /tmp/l3
gcc -o /home/flag03/l3 /tmp/l3.c
chmod +s,a+rwx /home/flag03/l3

/tmp 中生成的可执行文件未按预期提升权限，但/home/flag03 中生成的可执行文件按预期工作。

注意我刚刚新建了一个bash脚本，将/tmp中编译的setuid程序的版本移动到/home/flag03，然后重置setuid位。从那里执行时，该版本也可以正常工作。所以在我看来，setuid 程序所在目录的权限对进程的启动方式有某种影响。也许这与/tmp 是一个有点“特殊”的目录有关？

感谢您对这个冗长的问题感兴趣！

【问题讨论】：

你能检查/tmp/l3和/home/flag03/l3的所有者吗？他们是否都有相同的所有者 flag03 或其他？
对于 Stack Overflow，您的问题可能有点 off topic。它可能更适合我们的姐妹网站security.stackexchange.com 或unix.stackexchange.com。
@tian_yufeng 他们确实拥有相同的所有者，因为它们都被编译为相同的使用（然后chmod'd）。

标签： linux security exploit setuid

【解决方案1】：

如果文件系统使用nosuid 选项挂载，则在执行位于该位置的文件时将忽略 suid 位。据我了解，/tmp 通常是使用nosuid 选项安装的单独文件系统（通常是tmpfs）。此配置的动机是防止除了/tmp（例如nobody）之外没有可写存储的受感染帐户能够生成suid 二进制文件，该二进制文件可用于某些精心设计的多步攻击以提升权限。

【讨论】：