265

The setuid permission bit tells Linux to run a program with the effective user id of the owner instead of the executor:

> cat setuid-test.c

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

int main(int argc, char** argv) {
    printf("%d", geteuid());
    return 0;
}

> gcc -o setuid-test setuid-test.c
> ./setuid-test

1000

> sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
> ./setuid-test

65534

However, this only applies to executables; shell scripts ignore the setuid bit:

> cat setuid-test2

#!/bin/bash
id -u

> ./setuid-test2

1000

> sudo chown nobody ./setuid-test2; sudo chmod +s ./setuid-test2
> ./setuid-test2

1000

Wikipedia says:

Due to the increased likelihood of security flaws, many operating systems ignore the setuid attribute when applied to executable shell scripts.

Assuming I'm willing to accept those risks, is there any way to tell Linux to treat the setuid bit the same on shell scripts as it does on executables?

If not, is there a common workaround for this problem? My current solution is to add a sudoers entry to allow ALL to run a given script as the user I want it run as, with NOPASSWD to avoid the password prompt. The main downsides to that is the need for a sudoers entry every time I want to do this, and the need for the caller to sudo some-script instead of just some-script

codehead
  • 4,960
Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233

11 Answers11

280

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:

  1. The kernel opens the executable, and finds that it starts with #!.
  2. The kernel closes the executable and opens the interpreter instead.
  3. 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.

  1. The kernel opens the executable, and finds that it starts with #!. Let's say the file descriptor for the executable is 3.
  2. The kernel opens the interpreter.
  3. 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).

¹ This discussion applies equally if you substitute “setgid” for “setuid”; they are both ignored by the Linux kernel on scripts

Stephen Kitt
  • 434,908
  • Wow, you just scared the crap out of me, and I think I need to spend the next 4 days re-writing a lot of shell scripts in native code instead! ;-) – Josh Dec 11 '10 at 13:16
  • 4
    @Josh: Secure setuid shell scripts are possible, but only if the both the shell implementer and the script writer are very careful. Rather than native code, I recommend Perl, where the implementers have taken care that setuid scripts should be secure with little effort on the script writer's part. – Gilles 'SO- stop being evil' Dec 11 '10 at 13:52
  • 4
    apparently the suidperl stuff has been deprecated and marked for removal for years (but persists non-the-less) – jmtd May 12 '11 at 14:32
  • 1
    are there any other languages that support setuid safely? – ctrl-alt-delor Jun 28 '11 at 09:35
  • 8
    Actually suidperl has been removed as of perl 5.11 (5.12 stable):

    perl5110delta:

    "suidperl" has been removed. It used to provide a mechanism to emulate setuid permission bits on systems that don't support it properly.

    perl5120delta:

    "suidperl" is no longer part of Perl. It used to provide a mechanism to emulate setuid permission bits on systems that don't support it properly.

    – Randy Stauner Jul 14 '11 at 17:40
  • 5
    Also note this line from perl 5.6.1 docs (nearly a decade ago)...

    perl561delta:

    Note that suidperl is neither built nor installed by default in any recent version of perl. Use of suidperl is highly discouraged. If you think you need it, try alternatives such as sudo first. See http://www.courtesan.com/sudo/ .

    – Randy Stauner Jul 14 '11 at 17:45
  • Doesn't sudo sanitize the environment (or can at least be set to do so)? – Demi Dec 28 '13 at 00:51
  • @Demetri Yes, sudo can sanitize the environment if configured appropriately (env_reset option). – Gilles 'SO- stop being evil' Dec 28 '13 at 00:53
  • 3
    I don't understand: this seems to be an explanation of the reasons for the problems, but is there an actual answer to the OP's question here? Is there a way to tell my OS to run setuid shell scripts? – Tom Mar 31 '15 at 13:36
  • @Tom No, unless you patch the kernel, or use *BSD. I've added an explicit note about patching the Linux kernel. – Gilles 'SO- stop being evil' Mar 31 '15 at 19:01
  • What old system are you using that hasn't closed the LD_PRELOAD and LD_LIBRARY_PATH holes yet? Normally the loader just ignores them if ruid != euid. – Joshua Apr 18 '17 at 17:57
  • @Joshua None. I wrote “All sane systems ignore the LD_* variables in setuid executables”. – Gilles 'SO- stop being evil' Apr 18 '17 at 18:16
  • 1
    Commenting on the situation, not your explanation: This approach is so damn shortsighted. It makes not only attacks harder, but also good practices, such as running things under a separate, restricted account. – foo Dec 19 '18 at 17:03
  • OpenBSD (6.5 and 6.6 snapshot as of 2019) comes with "secure" setuid scripts enabled by default; no kernel setting has to be enabled. See my demo. –  Oct 16 '19 at 17:02
  • And suidperl went the way of the dodo a long time ago –  Oct 16 '19 at 17:13
  • Note that setuid on interpreted programs is now possible when using binfmt_misc with the "C" flag. – multithr3at3d Feb 24 '24 at 16:37
74

One way of solving this problem is to call the shell script from a program that can use the setuid bit.
its something like sudo. For example, here is how you would accomplish this in a C program:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
    setuid( 0 );   // you can set it at run time also
    system( "/home/pubuntu/setuid-test2.sh" );
    return 0;
 }

Save it as setuid-test2.c.
compile
Now do the setuid on this program binary:

su - nobody   
[enter password]  
chown nobody:nobody a.out  
chmod 4755 a.out  

Now, you should be able to run it, and you'll see your script being executed with nobody permissions.
But here also either you need to hardcode the script path or pass it as command line arg to above exe.

muru
  • 72,889
Hemant
  • 6,910
  • 5
  • 39
  • 42
  • 32
    I would advise against the suggestion to allow passing of the script as a command line argument, as that essentially gives anyone who can execute the program the ability to run any script as that defined user. – dsp Aug 12 '10 at 08:05
  • 2
    I would add some sanity checking if you implement that C solution: ensure that the script being run is owned by the right user+group, is not world-writable, and not of the directories in its path are world- or group-writable (essentially the same checks that suPHP performs) - this will reduce the chance of your tool becoming a security problem through other users being able to somehow edit or replace the script. – David Spillett Aug 12 '10 at 16:14
  • I voted down for suggestion of passing as parameter. IT WOULD MEAN ANY SCRIPT CAN BE RUN WITH ROOT PRIVILAGES. YES - ONE CONTAINING rm -rf / AS WELL. – Maja Piechotka Aug 17 '10 at 10:54
  • @Maciej: your point is valid.
    My assumption was from original Q. "Assuming I'm willing to accept those risks, is there any way to tell Linux to treat the setuid bit the same on shell scripts as it does on executables?"
    – Hemant Aug 17 '10 at 11:50
  • @Hemant: The problem is that passing script as parameter means that I can execute any script (i.e. effectively giving any user root rights). Giving setuid to one program does not involve such risk. – Maja Piechotka Aug 17 '10 at 19:47
  • 59
    Note that THIS IS INSECURE even if the full path to the script is hardcoded. The shell will inherit variables from the environment, and many of them allow the invoker to inject arbitrary code. PATH and LD_LIBRARY_PATH are obvious vectors. Some shells execute $ENV or $BASHENV or ~/.zshenv even before they start executing the script proper, so you can't protect from these at all from within the script. The only safe way to invoke a shell script with privileges is to clean up the environment. Sudo knows how to do it safely. So do not write your own wrapper, use sudo. – Gilles 'SO- stop being evil' Oct 08 '10 at 20:26
  • 40
    I feel bad that he's suddenly getting downvoted for this -- I did specifically say I wanted to hear insecure versions too, and I was imagining an executable that took a shell script argument when I said it. Obviously it's massively insecure, but I wanted to know what possibilities exist – Michael Mrozek Oct 08 '10 at 22:58
  • 10
    @Gilles: FYI, Linux unsets LD_LIBRARY_PATH among other things when it encounters the setuid bit. – u1686_grawity Feb 15 '12 at 15:31
  • 3
    Instead of using system, you may find it simpler (and more efficient) to use one of the exec family - most likely execve. That way, you don't create a new process or start a shell, and you can forward arguments (assuming that your privileged script can safely handle arguments). – Toby Speight Jul 23 '15 at 18:52
  • 2
    Excellent suggestion! We don't need our forks taken from us if we want to use them in dangerous ways... ;) – ylluminate May 28 '16 at 22:13
  • 3
    I'm surprized how come nobody asked what if we write a C program and set it's setuid bit where this C program will calculate the script's checksum (eg. sha1) and filesize, and will run the script with sudo if those results match with the ones hardcoded in the same C program. – ceremcem Nov 27 '16 at 09:59
  • Related: https://unix.stackexchange.com/questions/166817/using-the-setuid-bit-properly https://unix.stackexchange.com/questions/130906/why-does-setuid-not-work – phyatt Mar 15 '18 at 18:46
30

I prefix a few scripts that are in this boat thus:

#!/bin/sh
[ "root" != "$USER" ] && exec sudo $0 "$@"

Note that this does not use setuid but simply executes the current file with sudo.

Luc
  • 3,610
rcrowley
  • 1,163
  • 8
    This does not use setuid but just gives you a sudo prompt. (For me, the whole point of setuid is allowing things to run as root without needing sudo.) – Luc Dec 12 '18 at 21:13
  • 3
    @Luc This does not give you a sudo prompt if you use the NOPASSWD tag in your sudoers file, as the OP said that he does. I use this method as well and it also has the extra environment sanitation that sudoers provides. – dannyw Jul 26 '20 at 22:59
  • 1
    @dannyw Ah yes, fair enough. I guess there was a mismatch between my expectations given the title (and the answer I was looking for, coming from a search engine) and what OP actually wrote in their question. I can't remove the downvote, though...... "You last voted on this answer Dec 13 '18 at 8:26. Your vote is now locked in unless this answer is edited." wtf stackexchange – Luc Jul 26 '20 at 23:28
  • To add: I find this a perfect solution. Sometimes I have to run a script as root (because it needs to load SSL files and run gunicorn on :443), but sometimes just want to run it plain HTTP on :80 so no root required. This way always run it as user and only ask password if needed. – Robin van Leeuwen Apr 03 '23 at 10:41
15

If you want to avoid calling sudo some_script you can just do:

  #!/usr/bin/env sh

sudo /usr/local/scripts/your_script

SETUID programs need to be designed with extreme care as they run with root privileges and users have large control over them. They need to sanity-check everything. You cannot do it with scripts because:

  • Shells are large pieces of software which interact heavily with user. It is nearly impossible to sanity check everything — especially since most of the code is not intended to run in such mode.
  • Scripts are a mostly quick'n'dirty solution and usually are not prepared with such care that they would allow setuid. They have many potentially dangerous features.
  • They depend heavily on other programs. It is not sufficient that the shell was checked. sed, awk, etc. would need to be checked as well

Please note that sudo provides some sanity-checking but it isn't sufficient — check every line in your own code.

As a last note: consider using capabilities. They allow you to give a process running as a user special privileges that would normally require root privileges. However for example, while ping needs to manipulate the network, it does not need to have access to files. Capabilities can optionally be inherited to sub-processes.

  • 4
    I presume /ust/bin/env should be /usr/bin/env. – Bob Apr 18 '17 at 16:07
  • Or you can use the -S env option to make your script directly runable without having to embed it's name: #!/usr/bin/env -S -i MYVAR=foo sudo --preserve-env perl -w -T as described in answer for https://stackoverflow.com/questions/21597300/can-i-setuid-for-perl-script/74495557#74495557 – Britton Kerin Nov 18 '22 at 21:39
10

If for some reason sudo is not available, you can write a thin wrapper script in C:

#include <unistd.h>
int main() {
    setuid(0);
    execle("/bin/bash","bash","/full/path/to/script",(char*) NULL,(char*) NULL);
}

And once you compile it set it as setuid with chmod 4511 wrapper_script.

This is similar to another posted answer, but runs the script with a clean environment and explicitly uses /bin/bash instead of the shell called by system(), and so closes some potential security holes.

Note that this discards the environment entirely. If you want to use some environmental variables without opening up vulnerabilities, you really just need to use sudo.

Obviously, you want to make sure the script itself is only writable by root.

Chris
  • 1,539
  • 1
    I created an utility that is able to create this kind of binary executable wrappers: https://github.com/thiagorb/suid-wrapper/, without the need to write a new C program or compile it everytime. – Thiago Barcala Aug 07 '21 at 17:35
  • 1
    @ThiagoBarcala the point of using a thin wrapper script is to make it as bullet proof as possible. Can you say with confidence your program contains zero bugs? – Chris Aug 07 '21 at 18:44
  • 1
    Just at a glance you use strcpy to copy a path into a buffer of length PATH_MAX. But Linux doesn't actually do a good job of enforcing that paths are shorter than PATH_MAX, so that's a potential buffer overflow. – Chris Aug 07 '21 at 18:47
  • Not at all! It is extremely experimental, considering I just wrote it, and barely used it myself. – Thiago Barcala Aug 07 '21 at 18:47
  • BTW, I fixed the potential overflow. Thanks for pointing it out! – Thiago Barcala Aug 07 '21 at 19:42
9

super [ -r reqpath] command [ args ]

Super allows specified users to execute scripts (or other commands) as if they were root; or it can set the uid, gid, and/or supplementary groups on a per-command basis before executing the command. It is intended to be a secure alternative to making scripts setuid root. Super also allows ordinary users to supply commands for execution by others; these execute with the uid, gid, and groups of the user offering the command.

Super consults a ``super.tab'' file to see if the user is allowed to execute the requested command. If permission is granted, super will exec pgm [ args ], where pgm is the program that is associated with this command. (Root is allowed execution by default, but can still be denied if a rule excludes root. Ordinary users are disallowed execution by default.)

If command is a symbolic link (or hard link, too) to the super program, then typing % command args is equivalent to typing % super command args (The command must not be super, or super will not recognize that it's being invoked via a link.)

http://www.ucolick.org/~will/RUE/super/README

http://manpages.ubuntu.com/manpages/utopic/en/man1/super.1.html

  • Hi and welcome to the site! We expect answers to be more detailed here. Could you [edit] your answer and explain what this program is and how it could help solve the OP's problem? – terdon Jan 27 '15 at 13:09
  • Thank you Nizam, for hours trying to find something like super for accounts to be allowed to be executed by another user as the user of the file. – Chad Sep 14 '16 at 15:39
5

You can compile the script with a newer version of shc with the -S argument (enable SETUID) set.

shc -S -f your-script.sh
chmod u+s your-script.sh.x

your-script.sh.x would be the executable that can be used by a regular user.

ZigZagT
  • 151
  • Why was this downvoted? – Kai Petzke Jul 31 '21 at 16:30
  • I think that the downvotes are based on the fact that this solution may have the same security risks as described in the top answer. However, this solution is actually a valid one, in particular, because the question explcitly states that the administrator is will to take the risks. So I'm puzzled by the downvotes as well :) – Marcus Sep 18 '22 at 20:13
  • truth is every single method mentioned under this question has tradeoffs. There's no perfect answer. – ZigZagT Sep 19 '22 at 23:57
4

You can create an alias for sudo + the name of the script. Of course, that is even more work to set up, since you then have to setup an alias, too, but it saves you from having to type sudo.

But if you don't mind horrible security risks, use a setuid shell as the interpreter for the shell script. Don't know whether that'll work for you, but I guess it might.

Let me state that I advise against actually doing this, though. I'm just mentioning it for educational purposes ;-)

wzzrd
  • 3,720
  • 7
    It will work. Horribly as you stated. SETUID bit allows execution with the owner right. Setuid shell (unless it was designed to work with setuid) will run as root for any user. I.e. anyone can run rm -rf / (and other commands from series DON'T DO IT AT HOME). – Maja Piechotka Aug 17 '10 at 10:52
  • 14
    @MaciejPiechotka by DON'T DO IT AT HOME you mean Feel free to do that at work? :) – peterph Feb 27 '14 at 21:22
1

First, a disclaimer: the OP said "Assuming I'm willing to accept those risks, ...". I found myself in a similar situation where I had some one-off tasks where I was not concerned with security risks, because it was a short-term situation... Before you haters downvote, this is what the OP wanted...

So all my solution is is an extension of what Hemant came up with above. The only difference from his solution is a bit of automation so that you can both hard-code a specific executable you want to launch, but with a one-liner that's sort of like a combination of ln and setuid (e.g. chmod 6755).

Some would say it's overkill for something that you "ought not do in the first place" -- but again, that's what the OP wanted... About half the code could be deleted if you don't care about debugging options; I wanted the ability to turn on xtrace, and some of the debug features were just to help me develop it...

And to repeat, if it wasn't clear already: just plain sudo is a better option in nearly every case, except for sheer trade-off between laziness and speed... (I agree with most of the other posts)

Here is the code:

cat > makeSetUIDExecutable <<\ENDSCRIPT
#!/bin/bash

usage() { echo "Usage: $0 -c <command> -o <output> [-u <user>] [-v (verbose)] [-x (xtrace)] [-X (xtrace inherit)]" 1>&2; exit 1; }

PrintArray() { local -n arr=$1 echo -n "$1: " for elem in "${!arr[@]}"; do echo -n "[${elem@Q}]=${arr[$elem]@Q}, " done | sed 's/, $//'; echo }

PrintVariable() { echo "$1: ${!1}" }

unset makeSetUIDExecutableOpts quotedCommand declare -A makeSetUIDExecutableOpts

OPTIND=1 while getopts ":c:o:u:vxX" makeSetUIDExecutableOpt; do # echo -e "\nProcessing argument...\nmakeSetUIDExecutableOpt = ${makeSetUIDExecutableOpt}\nOPTARG = ${OPTARG}" [[ "${makeSetUIDExecutableOpt}" == ":" ]] && usage makeSetUIDExecutableOpts["${makeSetUIDExecutableOpt}"]="${OPTARG}" done

[[ -z "${makeSetUIDExecutableOpts[c]}" ]] || [[ -z "${makeSetUIDExecutableOpts[o]}" ]] && usage

[[ "${makeSetUIDExecutableOpts[x]+-}" ]] && { set -x trap "set +x" EXIT }

makeSetUIDExecutableOpts[u]="${makeSetUIDExecutableOpts[u]:-root}" userID=$(id -u "${makeSetUIDExecutableOpts[u]}")

[[ "${makeSetUIDExecutableOpts[X]+-}" ]] && quotedCommand="set -x; " quotedCommand+="${makeSetUIDExecutableOpts[c]//\&quot;/\\&quot;}" quotedCommand="&quot;${quotedCommand//&quot;/\&quot;}&quot;"

[[ "${makeSetUIDExecutableOpts[v]+-}" ]] && { echo -e "\nSummary -- Arguments provided:\n" PrintArray makeSetUIDExecutableOpts echo PrintVariable quotedCommand echo }

cat > "${makeSetUIDExecutableOpts[o]}.c" <<ENDSUBSCRIPT #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #include <errno.h>

int main() {

if( setuid( ${userID} ) ) {
    printf(&quot;setuid failed, errno = %i\n&quot;, errno);
}
system( ${quotedCommand} );
return 0;

}

ENDSUBSCRIPT

cc "${makeSetUIDExecutableOpts[o]}.c" -o "${makeSetUIDExecutableOpts[o]}"

sudo chown "${makeSetUIDExecutableOpts[u]}" "${makeSetUIDExecutableOpts[o]}" sudo chmod 6755 "${makeSetUIDExecutableOpts[o]}"

ENDSCRIPT

Example usage - a rather large command, to prove three-ways that all the user info is as-expected... Your command can be one word or ten lines...:

printUidGidInfo='set -- $(cat /proc/self/status | grep -P -o "(?<=Uid:|Gid:).*$"); unset outputString; i=1; while [ ${i} -le 4 ]; do outputString=${outputString}"\n"$(id -nu ${1}); shift; i=$(( i + 1 )); done; while [ ${i} -le 8 ]; do temp=$(getent group ${1}); outputString=${outputString}"\n"${temp%%:*}; shift; i=$(( i + 1 )); done; printf "\nReal UID: %s\nEffective UID: %s\nSaved set UID: %s\nFilesystem UID: %s\nReal GID: %s\nEffective GID: %s\nSaved set GID: %s\nFilesystem UID: %s\n\n" ${outputString}'

./makeSetUIDExecutable -c 'echo; echo "id -u -n:"; id -u -n; echo; echo stat -c "User: %U, Group: %G" /proc/$$/; stat -c "User: %U, Group: %G" /proc/$$/; echo; echo "/proc/self/status"; '"${printUidGidInfo}" -o proveUserInfo -v

./proveUserInfo

Output:

id -u -n:
root

stat -c User: %U, Group: %G /proc/10977/ User: root, Group: users

/proc/self/status

Real UID: root Effective UID: root Saved set UID: root Filesystem UID: root Real GID: users Effective GID: users Saved set GID: users Filesystem UID: users

Sean
  • 123
-1

IMPORTANT NOTE: the task described in the original question can be achieved in a safe way using sudo and sudoers configurations. Regardless of negative votes, this answer is going to stay for people that are still committed in running scripts with setuid, also after being warned of security implications. The method described also put bases for writing a more robust treatment of environment, like the one in sudo. Suggestions are welcome in chat.

The below shell script will create an a native wrapper with setuid and a given script embedded.

DISCLAIMER: READ CAREFULLY

To use the following snippet in a safe manner, some assumptions are necessary:

  1. the setuid executables created must be read only;
  2. the embedded script should be trusted and not being able to create security holes, such as execute another arbitrary script in the filesystem;
  3. The interpreter of your script, ant the script itself, should not be sensitive to environment manipulation attacks, such as modifying environment variables to force execution of untrusted code;
  4. The system is not already compromised, such as executables in system PATH reachable directories were already replaced with malicious versions.

If you can't guarantee the above conditions, or if you don't accept the security risks involved in being able to run trusted or non-trusted scripts with setuid, stop reading now. Also the native wrapper is probably incomplete at mitigating some common environment manipulation attacks, so use it at your own risk. Suggestions to improve the code are welcome.

If you read the above warning, and you think you'll be able to guarantee the above conditions, or you can ensure safety of your system by other means, create a file create-setuid-wrapper.sh as it follows:

#!/usr/bin/env bash
set -e

if [[ id -u != 0 ]]; then echo "Execute this command with super user credentials" exit 1 fi

if [[ $# -ne 1 || ! -f $1 ]]; then echo "A file argument is necessary" exit 1 fi

INPUT=$1 TEMPFOLDER=/tmp/tmpsuidwrapper TEMPINPUT=$TEMPFOLDER/input.data TEMPINPUTOBJ=$TEMPFOLDER/input.o WRAPPERSRC=$TEMPFOLDER/wrapper.c OUTFILE=$(basename -- "$INPUT") OUTFILE="${OUTFILE%.*}.bin"

Create temporary directory and copy the input

mkdir -p $TEMPFOLDER cp $INPUT $TEMPINPUT

Write wrapper source

cat > $WRAPPERSRC <<- EOF #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <err.h> #include <errno.h> #include <unistd.h> #include <sys/types.h> #include <sys/mman.h> #include <sys/wait.h>

extern const char _binary_input_data_start[]; extern void* _binary_input_data_size;

int main (int argc, char *argv[]) { int rc = setuid(0); if (rc == -1) { perror("setuid failed"); return -1; }

int fd = memfd_create(&quot;script&quot;, 0);
if (fd == -1)
{
    perror(&quot;memfd_create failed&quot;);
    return -1;
}

size_t size = (size_t)&amp;_binary_input_data_size;
rc = write(fd, _binary_input_data_start, size);
if (rc == -1)
{
    perror(&quot;write failed&quot;);
    return -1;
}

// Clean the environment to protect from some common
// environment manipulation attacks
// CHECK-ME: Check if some variables unset is actually needed
// and if more variables should be unset, sanitize
unsetenv(&quot;LD_LIBRARY_PATH&quot;);
unsetenv(&quot;LD_PRELOAD&quot;);
unsetenv(&quot;BASHENV&quot;);
unsetenv(&quot;ENV&quot;);
setenv(&quot;PATH&quot;, &quot;${PATH}&quot;, 1);

pid_t pid = fork();
if (pid == 0)
{
    // Child process, execute the script
    {
        const char * const argv[] = { &quot;script&quot;, NULL };
        const char * const envp[] = { NULL };
        int rc = fexecve(fd, (char * const *) argv, (char * const *) envp);
        if (rc == -1)
        {
            perror(&quot;fexecve failed&quot;);
            return -1;
        }
    }
}
if (pid == -1)
{
    perror(&quot;fork failed&quot;);
    return -1;
}

// Parent process
wait(NULL);
return 0;

} EOF

NOTE: Crappy 'ld' syntax apparenty doesn't allow to

specify a name for the symbol being created, so it will

use path as the name. We move the input to temp folder

to keep the symbol name short

CWD=pwd cd $TEMPFOLDER

Create a linkable object with the data to be embedded

ld -r -b binary -o input.o input.data cd $CWD

Compile the program and set setuid

cc -fPIC -no-pie -o $OUTFILE $WRAPPERSRC $TEMPINPUTOBJ chmod 4755 $OUTFILE

Cleanup

rm -fr $TEMPFOLDER

Then prepare, as an example, a test.py script like the following:

#!/usr/bin/env python3
import getpass
print(getpass.getuser())

Call create_setuid_wrapper.sh with the above test.py . The script will produce an executable test.bin. Ensure your system allow execution of arbitrary executables with setuid (SELinux enabled systems will not). Execution will print root or the name of your super user.

EDIT1: Removed copy to temporary file on the setuid executable. Now the embedded script is just executed directly from memory with a fork and a fexecve.

EDIT2: Attempt to clean the environment from some common environment manipulation attacks. It may be wrong and/or insufficient.

ceztko
  • 115
  • 2
    The produced test.bin will allow anybody to run any command as root. –  Feb 04 '21 at 21:40
  • That's the point of setuid anyway. You still need root to create such wrapper. – ceztko Feb 04 '21 at 21:50
  • 3
    You don't get it? Once created, test.bin will allow anybody to run any command as root, not just whoami. Just think what will happen if a regular user runs ln -fs /lib/<...>/libc.so.6 /tmp/tmpsetuidexec before running test.bin. And that's just one of the thousand ways you can exploit that. –  Feb 04 '21 at 21:54
  • If the existence of the temporary file it's your only concern, that is fixable by piping the embedded resource to a shell process in the same process, without creating the temporary file. I can do it later, or when I have time. – ceztko Feb 04 '21 at 21:59
  • 1
    It will still allow anybody to run any command as root, even then. –  Feb 04 '21 at 22:00
  • Thats the point of setuid, whats wrong with that? If I create a compiled program that reproduces the exact behavior of an unsecure script, I still have the security hole and the system will not be able from stopping me from doing it anyway. setuid should be used only on trusted stuff, like on all the compiled programs where it is set. – ceztko Feb 04 '21 at 22:03
  • 1
    No, that's not the point of setuid. Notice that test.bin will allow anybody to run any command (sorry for repeating ;-)), and do it irrespective of the content of its source test.sh script. Yes, most other answers are just as bad. –  Feb 04 '21 at 22:07
  • The copy on temporary file on the setuid executable has been removed. Now the embedded script is executed directly with fork and fexecve – ceztko Feb 05 '21 at 21:11
  • I added proper disclaimer and assumptions needed to use this tool safely. All downvotes will be just be assumed as junk unless properly motivated. – ceztko Feb 05 '21 at 22:48
  • Your program still allows any regular user to run any command as root -- you would have to remove and/or sanitize all the environment variables. Just for a start. I see that you had removed the example script -- well, even a file containing just #! /bin/bash can be exploited to run any command when "compiled" into a setuid binary with your script. As to a setuid binary having to be read-only, I don't see how that helps with anything at all ;-) –  Feb 06 '21 at 17:36
  • And btw, notice that the answer you link to is replete with bogus and outdated information. E.g. wrt Linux -- if you really want to break your Linux system, you can easily configure it to run setuid scripts via binfmt_misc -- no need to patch the kernel, or turn scripts into binaries (as in your answer and many others) –  Feb 06 '21 at 17:43
  • @UncleBilly Having the executable read-only inhibits from modifying the embedded string. The script now run from an in memory file descriptor and and can't be replaced externally, so I don't see a vulnerability linked to just embedding a shebang script in the executable. The race condition described in the same post above which allows arbitrary commands execution doesn't apply, please check the updated version of my script. Also I introduced rudimental environment variables sanitizing, which is incomplete but the number of common variables that need sanification is finite so it's a doable task – ceztko Feb 06 '21 at 20:14
  • No, the environment variables which have to be sanitized when running a shell are NOT a closed set. E.g. with your original sample script (which was using the #! /usr/bin/env bash cargo cult shebang), trivially changing the PATH would allow anybody to run any command instead of its content. But that is not the only to do it, and not even explicitly running /bin/bash with and empty script is safe. –  Feb 06 '21 at 21:23
  • As to read-only, etc the kernel will wipe any setuid bits when other users than the root are modifying a file, and the root can disregard read/write permissions anyway. –  Feb 06 '21 at 21:23
  • Added PATH sanitization, such as the PATH value is the same as the time embedding of the script into the native wrapper took place. Super user should be responsible in ensuring the script will execute correctly at a later stage. Ensuring the system is non compromised when running the script is also key in ensuring it doesn't open doors to security holes, but this holds for all scripts execution, also regular root executed ones. – ceztko Feb 08 '21 at 09:24
  • @UncleBilly I noticed your objections diminished in merit since I moved the embedded script to a python one. To each of your correct arguments, there's probably a proper countermeasure/mitigation, such as fixing PATH at the moment of embedding. More important, there's nothing like a permanent formally verifiable security of the system: a compromised system can introduced holes in all existing script execution, also regular root executions. Restricting scripts embedding to a subset of supported/trusted interpreters would also be key in being able to formally prove security of such method – ceztko Feb 08 '21 at 09:34
-4

I first found this question, unconvinced by all the answers, here is a much better one, which also allows you to completely obfuscate your bash script, if you are so inclined!

It should be self-explanatory.

#include <string>
#include <unistd.h>

template <typename T, typename U>
T &replace (
          T &str, 
    const U &from, 
    const U &to)
{
    size_t pos;
    size_t offset = 0;
    const size_t increment = to.size();

    while ((pos = str.find(from, offset)) != T::npos)
    {
        str.replace(pos, from.size(), to);
        offset = pos + increment;
    }

    return str;
}

int main(int argc, char* argv[])
{
    // Set UUID to root
    setuid(0);

    std::string script = 
R"(#!/bin/bash
whoami
echo $1
)";

    // Escape single quotes.
    replace(script, std::string("'"), std::string("'\"'\"'"));

    std::string command;
    command = command + "bash -c '" + script + "'"; 

    // Append the command line arguments.
    for (int a = 0; a < argc; ++a)
    {
        command = command + " " + argv[a];
    }

    return system(command.c_str());
}

Then you run

g++ embedded.cpp -o embedded
sudo chown root embedded
sudo chmod u+s embedded
HalosGhost
  • 4,790