Linux下文件设置用户编码setuid详解
我们知道，Linux每个文件的详细属性都存储在一个stat结构中，可以用stat命令查看文件的详细属性，例如文件大小，修改时间，所属用户，文件权限等。
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* inode number */
mode_t st_mode; /* protection */
nlink_t st_nlink; /* number of hard links */
uid_t st_uid; /* user ID of owner */
gid_t st_gid; /* group ID of owner */
dev_t st_rdev; /* device ID (if special file) */
off_t st_size; /* total size, in bytes */
blksize_t st_blksize; /* blocksize for filesystem I/O */
blkcnt_t st_blocks; /* number of 512B blocks allocated */
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
在stat结构中，st_mode字段表示了文件的模式相关属性。下图是关于该字段的详细描述，可以发现st_mode通过一个8进制数字存储文件模式：
- 后三位分布表示了文件读、写、执行的权限以及文件的掩码mask信息
- 第4位表示文件的粘着位，设置用户组编号，设置用户编号信息
- 其他位表示了文件的类型信息（管道，设备，文件夹，普通文件等）
S_IFMT 0170000 bit mask for the file type bit fields S_IFSOCK 0140000 socket S_IFLNK 0120000 symbolic link S_IFREG 0100000 regular file S_IFBLK 0060000 block device S_IFDIR 0040000 directory S_IFCHR 0020000 character device S_IFIFO 0010000 FIFO S_ISUID 0004000 set-user-ID bit S_ISGID 0002000 set-group-ID bit (see below) S_ISVTX 0001000 sticky bit (see below) S_IRWXU 00700 mask for file owner permissions S_IRUSR 00400 owner has read permission S_IWUSR 00200 owner has write permission S_IXUSR 00100 owner has execute permission S_IRWXG 00070 mask for group permissions S_IRGRP 00040 group has read permission S_IWGRP 00020 group has write permission S_IXGRP 00010 group has execute permission S_IRWXO 00007 mask for permissions for others (not in group) S_IROTH 00004 others have read permission S_IWOTH 00002 others have write permission S_IXOTH 00001 others have execute permission
下面一段代码将对setuid的使用作出简单说明。父进程通过fork创建一个子进程，然后父进程和子进程将分别打印设置用户ID，最后父进程将会尝试创建一个新的文件。
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
int fd;
pid_t pid;
if ((pid = fork()) < 0) {
fprintf(stderr, "fork error\n");
exit(1);
} else if (pid == 0) {
printf("child real user id: %d\n", getuid());
printf("child effective user id: %d\n", geteuid());
} else {
sleep(1);
printf("parrent real user id: %d\n", getuid());
printf("parrent effective user id: %d\n", geteuid());
exit(0);
}
if ((fd = open(argv[1], O_CREAT | O_RDWR)) < 0) {
fprintf(stderr, "open error\n");
fprintf(stderr, "error: %s\n", strerror(errno));
}
close(fd);
return 0;
}
编译并执行程序，结果如下（用户roo的编号为1000）。
roo@roose:~$ ls -l a.out -rwxrwxr-x 1 roo roo 9174 Jan 29 17:17 a.out* roo@roose:~$ ./a.out /usr/local/testfile child real user id: 1000 child effective user id: 1000 parrent real user id: 1000 parrent effective user id: 1000 open error error: Permission denied
可以发现父进程和子进程的实际用户ID和有效用户ID都是1000，当我们尝试创建文件/usr/local/testfile时，程序提示权限错误。
下面修改a.out的属性，设置文件用户位root，并且修改设置用户ID。
roo@roose:$ sudo chown root:root a.out roo@roose:$ sudo chmod 4775 a.out roo@roose:$ ls -l a.out -rwsrwxr-x 1 root root 9174 Jan 29 17:17 a.out然后重新执行程序，可以发现进程的实际用户编号(uid)为执行用户的用户编号1000，但是有效用户编号(euid)是文件所属用户（即root）的用户编号0，而且子进程也集成了父进程的实际用户编号和有效用户编号。最好，父进程成功创建了/usr/local/testfile文件，说明程序是以root权限执行的。
roo@roose:~$ ./a.out /usr/local/testfile child real user id: 1000 child effective user id: 0 parrent real user id: 1000 parrent effective user id: 0
下面看另一个例子，创建脚本文件test.sh内容如下：
#!/bin/bash sleep 10 touch /usr/local/testfile同样对test.sh赋予相关权限并执行，然而却发现程序的实际用户编号(uid)和有效用户编号(euid)都是1000，而且程序也没有权限创建/usr/local/testfile，即添加的设置用户编号没有效果。
roo@roose:~$ sudo chown root:root test.sh roo@roose:~$ sudo chmod 4775 test.sh roo@roose:~$ ./test.sh & [1] 54280 roo@roose:~$ ps -eo uid,euid,command | grep test.sh 1000 1000 /bin/bash ./test.sh 1000 1000 grep --color=auto test.sh roo@roose:~$ touch: cannot touch ‘/usr/local/testfile’: Permission denied
通过查找相关资料，发现出现该问题的原因是：出于安全问题，Linux会忽略任何编译器文件的设置用户位，详细说明如下(博主太懒，有空再翻译)
http://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
Linux ignores the setuid¹ bit on all interpreted executables (i.e. executables starting with a #! line). The comp.unix.questions FAQ explains the security problems with setuid shell scripts. These problems are of two kinds: shebang-related and shell-related; I go into more details below.
If you don't care about security and want to allow setuid scripts, under Linux, you'll need to patch the kernel. As of 3.x kernels, I think you need to add a call to install_exec_creds in the load_script function, before the call to open_exec, but I haven't tested.Setuid shebang
There is a race condition inherent to the way shebang (#!) is typically implemented:
The kernel opens the executable, and finds that it starts with #!.
The kernel closes the executable and opens the interpreter instead.
The kernel inserts the path to the script to the argument list (as argv[1]), and executes the interpreter.
If setuid scripts are allowed with this implementation, an attacker can invoke an arbitrary script by creating a symbolic link to an existing setuid script, executing it, and arranging to change the link after the kernel has performed step 1 and before the interpreter gets around to opening its first argument. For this reason, most unices ignore the setuid bit when they detect a shebang.
One way to secure this implementation would be for the kernel to lock the script file until the interpreter has opened it (note that this must prevent not only unlinking or overwriting the file, but also renaming any directory in the path). But unix systems tend to shy away from mandatory locks, and symbolic links would make a correct lock feature especially difficult and invasive. I don't think anyone does it this way.
A few unix systems (mainly OpenBSD, NetBSD and Mac OS X, all of which require a kernel setting to be enabled) implement secure setuid shebang using an additional feature: the path /dev/fd/N refers to the file already opened on file descriptor N (so opening /dev/fd/N is roughly equivalent to dup(N)). Many unix systems (including Linux) have /dev/fd but not setuid scripts.
The kernel opens the executable, and finds that it starts with #!. Let's say the file descriptor for the executable is 3.
The kernel opens the interpreter.
The kernel inserts /dev/fd/3 the argument list (as argv[1]), and executes the interpreter.
Sven Mascheck's shebang page has a lot of information on shebang across unices, including setuid support.
Setuid interpreters
Let's assume you've managed to make your program run as root, either because your OS supports setuid shebang or because you've used a native binary wrapper (such as sudo). Have you opened a security hole? Maybe. The issue here is not about interpreted vs compiled programs. The issue is whether your runtime system behaves safely if executed with privileges.Any dynamically linked native binary executable is in a way interpreted by the dynamic loader (e.g. /lib/ld.so), which loads the dynamic libraries required by the program. On many unices, you can configure the search path for dynamic libraries through the environment (LD_LIBRARY_PATH is a common name for the environment variable), and even load additional libraries into all executed binaries (LD_PRELOAD). The invoker of the program can execute arbitrary code in that program's context by placing a specially-crafted libc.so in $LD_LIBRARY_PATH (amongst other tactics). All sane systems ignore the LD_* variables in setuid executables.
In shells such as sh, csh and derivatives, environment variables automatically become shell parameters. Through parameters such as PATH, IFS, and many more, the invoker of the script has many opportunities to execute arbitrary code in the shell scripts's context. Some shells set these variables to sane defaults if they detect that the script has been invoked with privileges, but I don't know that there is any particular implementation that I would trust.
Most runtime environments (whether native, bytecode or interpreted) have similar features. Few take special precautions in setuid executables, though the ones that run native code often don't do anything fancier than dynamic linking (which does take precautions).
Perl is a notable exception. It explicitly supports setuid scripts in a secure way. In fact, your script can run setuid even if your OS ignored the setuid bit on scripts. This is because perl ships with a setuid root helper that performs the necessary checks and reinvokes the interpreter on the desired scripts with the desired privileges. This is explained in the perlsec manual. It used to be that setuid perl scripts needed #!/usr/bin/suidperl -wT instead of #!/usr/bin/perl -wT, but on most modern systems, #!/usr/bin/perl -wT is sufficient.
Note that using a native binary wrapper does nothing in itself to prevent these problems. In fact, it can make the situation worse, because it might prevent your runtime environment from detecting that it is invoked with privileges and bypassing its runtime configurability.
A native binary wrapper can make a shell script safe if the wrapper sanitizes the environment. The script must take care not to make too many assumptions (e.g. about the current directory) but this goes. You can use sudo for this provided that it's set up to sanitize the environment. Blacklisting variables is error-prone, so always whitelist. With sudo, make sure that the env_reset option is turned on, that setenv is off, and that env_file and env_keep only contain innocuous variables.
TL,DR:
Setuid shebang is insecure but usually ignored.
If you run a program with privileges (either through sudo or setuid), write native code or perl, or start the program with a wrapper that sanitizes the environment (such as sudo with the env_reset option).