Shell Programming and Scripting

Well, like all good C progs, the path to libc.so or whatever, at least. Now, it might be /lib, but setuid erases even that from LD_LIBRARY_PATH, and ld does not think it is on him to look there unasked.

On HP-UX, a set-uid ksh script gets a message, so I guess they added explicit prevention, but on Solaris I do recall such: Setuid execution not allowed

Code:

$ ldd -rsv $(whence ksh)                    
ldd -rsv $(whence ksh)
  find library=/usr/lib/libc.2; required by /usr/bin/ksh
        /usr/lib/libc.2 =>      /usr/lib/libc.2
  find library=/usr/lib/libdld.2; required by /usr/lib/libc.2
        /usr/lib/libdld.2 =>    /usr/lib/libdld.2
  find library=/usr/lib/libc.2; required by implicit load
        /usr/lib/libc.2 =>      /usr/lib/libc.2
  find library=/usr/lib/libxti.2; required by /usr/bin/ksh
        /usr/lib/libxti.2 =>    /usr/lib/libxti.2
  find library=/usr/lib/libnsl.1; required by /usr/bin/ksh
        /usr/lib/libnsl.1 =>    /usr/lib/libnsl.1
  find library=/usr/lib/libxti.2; required by /usr/lib/libnsl.1
    search path=/usr/lib:  (RPATH)
    trying path=/usr/lib/libxti.2
        /usr/lib/libxti.2 =>    /usr/lib/libxti.2
$

On the platforms I use (*BSD, Linux, OSX), LD_LIBRARY_PATH is usually unset and the interpreters work fine. In my experience, LD_LIBRARY_PATH is usually used as a hack in environment-modifying shell script wrappers that launch oddball binaries which need help locating their libraries. Typically, it's not needed as shared libraries are in a system defined location which is searched by the loader regardless of the value of LD_LIBRARY_PATH or whether an executable is SUID.


There is, at least on some systems. For example, testing on Linux (an approximately 5 yr old Debian install running kernel version 2.6.18) shows that the SUID bit of an interpreted file has absolutely no effect. The only way to launch the interpreter under a different effective user id is to set the SUID bit on the interpreter itself.

Let's assume we've just called exec() on a SUID interpreted file.

The exec system call calls prepare_binprm(). prepare_binrpm() always sets the new process' effective [ug]id to the current [ug]id before checking the permissions of the script's inode. If the inode has the SUID bit set, then it modifies the euid for the new process to match the inode's uid.

So far, Linux's exec() conforms to historical behavior: the effective uid is set to the inode owner's uid. But, there's more to come. At this point the kernel does not know that it's dealing with an interpreted file. What has happened so far happens for all exec()s.

Later in the exec syscall, search_binary_handler() is called to walk a list of supported binary formats which point to their respective loaders. In the case of a text-file with a leading she-bang, it's load_script().

Thus begins a recursive loop. load_script() processes the she-bang, determines the interpreter to use, then replays the sequence above, calling prepare_binrpm() and then search_binary_handler(), but now the inode whose permissions are scrutinized is that of the interpreter not the script.

Each time it's called, prepare_binrpm() will clobber the new process' egid and euid (possibly previously modified by the script's SUID bit), resetting them to the current e[ug]id, before examining the interpreter's inode's SUID bit.

In the end, the SUID bit in the inode of the final file in the chain determines the euid of the exec'd process. The SUID bit of the originating script file is irrelevant.


exec.c/prepare_binrpm():

Code:

1205 /*
1206  * Fill the binprm structure from the inode.
1207  * Check permissions, then read the first 128 (BINPRM_BUF_SIZE) bytes
1208  *
1209  * This may be called multiple times for binary chains (scripts for example).
1210  */
1211 int prepare_binprm(struct linux_binprm *bprm)
1212 {

...<snip>...

1221         /* clear any previous set[ug]id data from a previous binary */
1222         bprm->cred->euid = current_euid();
1223         bprm->cred->egid = current_egid();
1224
1225         if (!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
1226                 /* Set-uid? */
1227                 if (mode & S_ISUID) {
1228                         bprm->per_clear |= PER_CLEAR_ON_SETID;
1229                         bprm->cred->euid = inode->i_uid;
1230                 }

exec.c/sys_execve():

Code:

1379 /*
1380  * sys_execve() executes a new program.
1381  */

...<snip>...

1435         retval = prepare_binprm(bprm);

...<snip>...

1452         retval = search_binary_handler(bprm,regs);
1453         if (retval < 0)
1454                 goto out;
1455
1456         /* execve succeeded */

binfmt_script.c/load_script():

Code:

17 static int load_script(struct linux_binprm *bprm,struct pt_regs *regs)
18 {

...<snip>...

87         /*
88          * OK, now restart the process with the interpreter's dentry.
89          */
90         file = open_exec(interp);
91         if (IS_ERR(file))
92                 return PTR_ERR(file);
93
94         bprm->file = file;
95         retval = prepare_binprm(bprm);
96         if (retval < 0)
97                 return retval;
98         return search_binary_handler(bprm,regs);
99 }

git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/blob - fs/exec.c
git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/blob - fs/binfmt_script.c


An older OSX Tiger (10.4.11) laptop appears to be even more restrictive: If the first file in the chain is a SUID interpreted file, the euid is never changed (not even when the interpreter and the interpreted file are both SUID).

Back to where this thread started, an old OpenBSD 4.4 system honors the SUID bit of interpreted files (modifying the euid as per historical practice, as per the interpreted file's inode permissions, regardless of the interpreter's permissions).

I really should update my disused machines to more current versions of their respective operating systems.

Regards,
Alister

---------- Post updated at 07:12 PM ---------- Previous update was at 06:52 PM ----------

I ran my tests using the following "interpreter" in my sh/ksh shebang:

Code:

#include <stdio.h>
#include <unistd.h>

int
main (int argc, char **argv) {
    printf("%lu\n", (unsigned long int) geteuid());
    return 0;
}

Regards,
Alister

So, it's implicitly impossible unless you have a setuid binary in the middle. I guess you could write a trivial re-executing program to setuid if you though it was a good idea.