In Linux, does the location of an executable affect how the setuid bit is interpreted?

Question

In a Linux system, does the permissions of the directory in which a setuid program resides affect how the kernel launches the process? The reason I ask is that when I compiled an identical setuid program in two different directories, it only actually assumed the user permissions in one directory. I compiled it in /tmp and /home/flag03 where flag03 is the user account that I am attempting to gain access to. When executed from /tmp it did not escalate privileges as expected, but it worked under /home.

Some background on the problem:

I'm working on level 03 of exploit-exercises.com/nebula. The exercise requires that you gain access to a flag03 user account. The exercise is setup so that the flag03 user is periodically running a cronjob which will allow you to execute a script in a specific directory. My plan was to write a simple bash script which will compile a setuid program that itself launches a bash shell, and then set the setuid bit with chmod +s. The idea is that when the setuid program is compiled, it is compiled by user flag03 via the cronjob. Once this newly compiled program is executed, it will launch a shell as user flag03, and that is the goal.

Here is the simple setuid program (l3.c, based on levels 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;
}

In order for this to work, a bash script compiles the program as user flag03 and then chmods the setuid bit.

#!/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

The executable generated in /tmp does not escalate privileges as expected, but the one generated in /home/flag03 works as expected.

NOTE I just created a new bash script to move the version of the setuid program that was compiled in /tmp to /home/flag03, and then reset the setuid bit. When executed from there, that version worked as well. So it appears to me that the permissions of the directory in which the setuid program resides has some kind of impact with how the process is launch. Maybe this is related to /tmp being a somewhat "special" directory?

Thanks for any interest in this long-winded question!

Can you check the owner of /tmp/l3 and /home/flag03/l3? Are they both have the same owner flag03 or else? — tian_yufeng, Mar 13 '13 at 06:02
Your question might be a bit [off topic](http://stackoverflow.com/faq) for Stack Overflow. It could be better suited for our sister sites, http://security.stackexchange.com/ or http://unix.stackexchange.com/. — Ilmari Karonen, Mar 13 '13 at 06:28
@tian_yufeng They both indeed had the same owner, as they were both compiled as the same used (and then chmod'd). — Mr. Shickadance, Mar 13 '13 at 12:32

score 3 · Answer 1 · answered Jul 16 '14 at 21:15

If the filesystem is mounted with the nosuid option, the suid bit will be ignored when executing files located there. As I understand it, /tmp is usually a separate filesystem (often tmpfs) mounted with the nosuid option. The motivation for this configuration is preventing a compromised account that has no writable storage except /tmp (e.g. nobody) from being able to produce suid binaries, which may be used in certain elaborate multi-step attacks to elevate privilege.

In Linux, does the location of an executable affect how the setuid bit is interpreted?

1 Answers1