在Linux系统中,setuid程序所在目录的权限是否影响内核启动进程的方式?我问的原因是,当我在两个不同的目录中编译一个相同的setuid程序时,它实际上只在一个目录中承担了用户权限。我在/tmp
和/home/flag03
中对其进行了编译,其中flag03
是我尝试访问的用户帐户。从/tmp
执行时,它没有按预期升级权限,但它在/home
下工作。
问题的一些背景:
我正在exploit-exercises.com/nebula的第03级工作。此练习要求您获得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
编译程序,然后chmods setuid位。
#!/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
是一个有点“特殊”的目录有关吗?
感谢您对这个冗长的问题感兴趣!
答案 0 :(得分:3)
如果使用nosuid
选项挂载文件系统,则执行位于此处的文件时将忽略suid位。据我了解,/tmp
通常是使用tmpfs
选项安装的单独文件系统(通常为nosuid
)。此配置的动机是阻止除/tmp
之外没有可写存储的受损帐户(例如nobody
)能够生成suid二进制文件,这可能会用于某些精心设计的多步攻击以提升特权。