13

I was experimenting a bit and noticed something strange: setting the setuid bit on a copy of bash located at /usr/bin/bash-test seemed to have no effect. When I ran an instance of bash-test, my home directory was not set to /root and when I ran the whoami command from bash-test, my username was not reported as being root, suggesting that bash-test was not running as root. However, if I set the setuid bit on whoami, I was reported as being root in any shell, as expected.

I tried setting the setuid bit on /usr/bin/bash as well and observed the same behavior.

Why is bash not running as root when I set the setuid bit on it? Could selinux have something to do with this?

  • 1
    you find additional info about the setuid in this question. – Anthon May 3 '13 at 4:53
  • Also see Setuid Demystified by Chen, Dean and Wagner. Its an old paper but it still applies. – user56041 Apr 26 '18 at 2:52
20

The explanation is kind of annoying: bash itself is the reason. strace is our friend (must be SUID root itself for this to work):

getuid()                                = 1000
getgid()                                = 1001
geteuid()                               = 0
getegid()                               = 1001
setuid(1000)                            = 0
setgid(1001)                            = 0

bash detects that it has been started SUID root (UID!=EUID) and uses its root power to throw this power away, resetting EUID to UID. And later even FSUID, just to be sure...:

getuid()                                = 1000
setfsuid(1000)                          = 1000
getgid()                                = 1001
setfsgid(1001)                          = 1001

In the end: no chance. You have to start bash with UID root (i.e. sudo).

Edit 1

The man page says this:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

But this does not work for me. -p isn't even mentioned among the startup options. I also tried --posix; didn't work either.

2

In any case, a SUID root program does not run with root's environment ($HOME, configuration for the shell, whatever), it runs with root powers (i.e., it can delete any file, change any permissions, etc).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy