I'm trying to check how the SUID works, and I have created a binary with the shc compiler from this script:

#!/bin/bash
echo "I'm the script"
sleep 5
cat /srv/test/secret

The binary is owned by user kali (/usr/bin/hehe). I added execution permissions and the SUID bit.

.rwsrwxr-x kali kali 15 KB Fri Feb  9 00:49:58 2024  /usr/bin/hehe

I'm trying to execute it with franlol user. As far as I understand, with the s bit, the file should be run by the user kali because he is the owner, even if it is executed by user franlol. Why the binary/script cannot do the cat to a file owned by the same user than the binary owner? What is not correct in this flow?

┌──(franlol㉿kali)-[~]
└─$ lsa -l /srv/test/secret
.rwx------ kali kali 26 B Fri Feb  9 00:46:01 2024  /srv/test/secret
                                                                                                                                       
┌──(franlol㉿kali)-[~]
└─$ lsa -l /usr/bin/hehe   
.rwsrwxr-x kali kali 15 KB Fri Feb  9 00:49:58 2024  /usr/bin/hehe
                                                                                                                                       
┌──(franlol㉿kali)-[~]
└─$ hehe
I'm the script
cat: /srv/test/secret: Permission denied

Also, while the execution is doing the 5s sleep, If I do a ps aux | grep hehe I see that the execution user is not Kali, and as far as I understand, if the hehe script is owned by the user kali, it should be run by the same owner.

I have a script in which I need to mount an overlay to give an OCI container access to a mounted read-only directory /nix/store as if it was writable. I would like to have this script be runnable by non-root/non-wheel users, what would be the easiest way? Initially, I naively tried using SUID before I realized that those didn't work, which lead me to a bunch of answers and articles on the dangers of SUID for shell scripts, including one that explained why merely wrapping it around some C program would not fix the security issues regarding non-clean environment. Is there an easy wrapper/utility I can wrap the script in that takes care of such vulnerabilities? From the user environment, I only need one ENV which is just passed to the docker container, however, the root user would have the same ENV variable in their bash session, therefore if a suggestion works by disregarding all the user environment and instead uses the root one, that would be fine for my use case.

local temp_dir=$(mktemp -d)

mkdir -p {$temp_dir/store,$temp_dir/upper-store,$temp_dir/work-store}

# Create Overlay
sudo mount -t overlay overlay \
  -o lowerdir=/nix/store,upperdir=$temp_dir/upper-store,workdir=$temp_dir/work-store $temp_dir/store

# Do some sutff with the mounted overlay

sudo umount $temp_dir/store
rm -rf $temp_dir

I have a suid-to-root executable that users should run only with certain parameters, env var settings and context setup. I can't modify that exe. I will wrap the exe in arg-less scripts, one for each allowed parameterization, env and context setup. The problem is how to allow the user to run these scripts but not run the exe other ways. Are there any security issues with my proposed solutions below or better alternatives? I don't know if polkit or sudo can accomplish this, but would be interested in how if anyone knows. I have 3 solutions: 1. use a mount namespace. Globally, mount the exe nosuid (it exits immediately if not run euid=0). Create a private mount namespace and remount the exe suid. Write a small suid exe with only arg = name of wrapper script, which enters the private namespace, drops privileges and runs the script. The wrapper scripts are all kept in a dedicated dir (/usr/local/bin/safescripts), hardcoded into the new small suid exe. The new exe always calls scripts only in that dir, which contains nothing else. 2. use a directory "vault". Create parent-child directory pair /usr/local/lock and /usr/local/lock/vault. Both are root:root owned, /usr/local/lock is 750, /usr/local/lock/vault is 755. Users cannot get to vault unaided. But once in vault, users can get at what's there. Move the original suid exe into /usr/local/lock/vault. Write a small suid exe that takes a basename of one of the scripts, chdirs into /usr/local/lock/vault, drops privileges and runs the script. Same setup for the wrapper scripts as in 1, but they must call the original exe using "./" prefixed pathname while staying in the cwd (vault). 3. handoff with elevated privileges (euid=0). Remove the suid bit on the original exe. Write a small suid exe that takes a basename of one of the scripts (as 1 and 2 above), and without dropping privileges, call the script (which must have #!/bin/bash -p) and allow the original exe to drop privileges itself. I consider 3 to be too risky because so much is run with euid=0, including scripts. Comparing the small exes of 1 and 2: 2 only does chdir (how bad can that be?) with euid=0, while 1 does an open of the bind-mounted suid namespace and setns to that fd - still small, but with more complex consequences. Also the setup of 1 requires a service to create the suid mount namespace and bind-mount it somewhere. Not much, but something. Alternatively, the new exe could create the mount namespace itself, but that makes it even more complex: it would have to call unshare and mount with elevated privs, both of which have many more options than open and setns. I am leaning towards 2, which seems to be safest/easiest, although the vault setup seems kludgy. Unless someone can offer a better way or sees issues with 2.

I am setting SUID for a new user tommy to run the same commands as root but it goes down like this:

[root@192 ~]# useradd tommy
[root@192 ~]# su - tommy
[tommy@192 ~]$ chmod u+s /usr/bin/ls
chmod: changing permissions of '/usr/bin/ls': Operation not permitted`

Do I need to add this user to sudoers file in order to execute this command successfully or what?

I've set the SUID & SGID bit on a folder belonging to user *foo* with sudo chmod g+s myfolder & sudo chmod u+s myfolder drwsr-sr-x 24 foo www-data 4,0K Okt 25 16:17 myfolder Then I went inside and created a folder with sudo mkdir xyz, but the user of the folder gets overwritten with root while the group was protected successfully. drwxr-sr-x 2 root www-data 4,0K Okt 25 16:24 xyz I expect the user to be protected, it should stay at foo after executing sudo mkdir xyz. What have I missed?

What is the difference between SUID and ACL file permission? Also, when should I use either?

The problem is that I want to run certain ssh commands (Or scripts) from computerA to computerB without using a password. Examples: ssh apple@computerB 'poweroff' ssh apple@computerB "killall firefox; systemctl enable apache; firefox" ssh apple@computerB < superscript.txt I also want to do this as secure as I can get it. I should not be able to ssh to computerB if I simply open up a terminal. And obviously not be able to edit the scripts/programs and run them afterwards. I was thinking about using SUID and a different user with ssh keys to access the computer but there are security concerns regarding SUID and interpreted scripts. Do anyone have any suggestions?

Let's say we have created a file with root account with -rwsr-xr-x script.sh permissions. We have set suid bit on this file so any user who is gonna execute this file, it's gonna be execute by owner of the file which is root. For example let's look at the passwd command: $ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 68208 Apr 16 17:06 /usr/bin/passwd This command is similar to our file. Any user who executes this command, it's going to be run as root account no matter if the user is root or has sudo privileges. The question is how can i verify this subject? To figure this out I'v tried this: if we look at script.sh contents, I'v wrote this simple script: #!/bin/bash if [[ $UID -eq 0 ]] then echo "Running as root" else echo "Not root" fi now if I run this script as a regular user, the output will be: Not root So how can I check if it's running as root? ---------- Please let me know if I have misunderstanding of the concepts. I'm a newbie.

What's the reason for using

-type f

with

/ -perm -u=s -type f 2>/dev/null

. I see this all over the Internet and don't understand why to specify the type as regular file if look for SUID bit set. SUID can be set only of files and not directories so why

-type f

? Or am I missing something ?

I'm hardening a Linux system and wanted to test (setuid-based) shell escapes using common binaries, like awk, vim, etc., supporting command executing. However, all binaries I've tested except sh and bash don't respect their setuid bit. In particular, awk continues to execute as a normal user: $ ls -lL /usr/bin/awk -rwsr-xr-x 1 root root 121976 Mar 23 2012 /usr/bin/awk $ id uid=1000(bob) gid=1000(bob) groups=1000(bob) $ awk 'BEGIN{system("id")}' uid=1000(bob) gid=1000(bob) groups=1000(bob) In contrast, bash executes as root when given the -p option: $ ls -la /bin/bash -rwsr-xr-x 1 root root 1168776 Apr 18 2019 /bin/bash $ /bin/bash -p # id uid=1000(bob) gid=1000(bob) euid=0(root) groups=1000(bob) Is there any way to make awk, vim, less, etc. respect the setuid bit and execute the command as root? **OS**: # cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/ " SUPPORT_URL="https://www.debian.org/support " BUG_REPORT_URL="https://bugs.debian.org/ " **Update**: parallels@debian-gnu-linux-vm:~$ ls -la /proc/self/fd/0 /dev/fd/0 /dev/stdin lrwx------ 1 parallels parallels 64 Mar 26 08:15 /dev/fd/0 -> /dev/pts/1 lrwxrwxrwx 1 root root 15 Mar 20 19:56 /dev/stdin -> /proc/self/fd/0 lrwx------ 1 parallels parallels 64 Mar 26 08:15 /proc/self/fd/0 -> /dev/pts/1

I created a simple script on Ubuntu Server 18.04: #!/bin/bash apt update apt upgrade then I changed the owner to root # chown root update.sh then I added SUID bit and execution bits for user and group # chmod u+xs,g+x update.sh and this is what I have: -rwsrwxr-- 1 root me 35 Mar 21 09:48 update.sh* So I was expecting that by running this script which I have permission to run (it belongs to my group), it gets the root UID and it will execute as root, but I get permission denied.

if i have /target mounted with suid and then make a bind-mount on /bound with mount -o bind,nosuid /target /bound, will nosuid take effect on /bound ? (imo it should take effect but i'd still like a definite answer, and nobody else had asked yet here or so it seems)

I'm experiencing a weird behavior regarding `setuid()` and the setuid bit. It seems like the suid bit and setuid() do not work as expected. I am expecting for a binary with +s and owned by uid 1001 that calls `setuid(1001)` to be called from any uid and assume uid 1001 after the call. Yet, that only seems to work if either: 1. +s is not set and the calling user is root 2. +s is set and the binary belongs to root I am expecting that I overlooked a detail, however I cannot find my error. The end goal would be to have a binary that can be called from any user and assume a fixed uid. I do not want it to be owned by root, but by the user whose identity should be assumed (mainly because this is an exercise on stack smashing and that would allow a priv esc). I created a minimal example to pin down my problems, and here it is: Consider test.c: #include #include #include #include #include int main() { int t = setuid(1001); if (t < 0) { perror("Error with setuid() - errno " + errno); } else { printf("did work fine, look who I am:.\n"); system("/bin/bash -c whoami"); } } Also, passwd looks like this in the relevant parts: test1:x:1000:1000::/home/test1:/bin/sh test2:x:1001:1001::/home/test2:/bin/sh Now, consider this output: root@kali:/tmp/test# ls -la total 12 drwxr-xr-x 2 root root 4096 Oct 24 09:53 . drwxrwxrwt 18 root root 4096 Oct 24 09:52 .. -rw-r--r-- 1 root root 304 Oct 24 09:51 test.c root@kali:/tmp/test# gcc test.c -o test root@kali:/tmp/test# ./test did work fine, look who I am:. test2 root@kali:/tmp/test# chown test2:test2 test root@kali:/tmp/test# ./test did work fine, look who I am:. test2 root@kali:/tmp/test# chmod +s test root@kali:/tmp/test# ./test did work fine, look who I am:. root root@kali:/tmp/test# su test1 $ ./test did work fine, look who I am:. test1 $ As you can see, there's no error showing, yet the desired uid is not assumed correctly. To add insult to injury, consider this: root@kali:/tmp/test# chown root:root test root@kali:/tmp/test# chmod +s test root@kali:/tmp/test# ./test did work fine, look who I am:. test2 root@kali:/tmp/test# su test1 $ ./test did work fine, look who I am:. test2 So I guess my question is: what am I doing wrong? Why does `setreuid() work and setuid()` doesn't? Other things I tried: Using `execve()`, reproducing under ubuntu 18.04, using /bin/sh instead of /bin/bash.

I have a script: [postgres@LaHarch ~]$ cat mkrundir.sh #!/bin/bash mkdir /run/postresql With attributes: [postgres@LaHarch ~]$ ll mkrundir.sh -rwsr-sr-x 1 root root 74 Aug 26 18:53 mkrundir.sh But when I run it I get: [postgres@LaHarch ~]$ ./mkrundir.sh mkdir: cannot create directory '/run/postresql': Permission denied Why SUID didn't help me? And what is best practice for such a task?

I know what it means for a file to have suid permission. It means when other users have execute permission for it, they execute as the owner of the file. But what does it imply when a folder has suid permission? I did some testing and it seems nothing special for the folder. Could anyone help to plain a little? Thanks. I'm using Oracle Linux 7.6. root:[~]# cat /etc/*release* Oracle Linux Server release 7.6 NAME="Oracle Linux Server" VERSION="7.6" ID="ol" VARIANT="Server" VARIANT_ID="server" VERSION_ID="7.6" PRETTY_NAME="Oracle Linux Server 7.6" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:7:6:server" HOME_URL="https://linux.oracle.com/ " BUG_REPORT_URL="https://bugzilla.oracle.com/ " ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7" ORACLE_BUGZILLA_PRODUCT_VERSION=7.6 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=7.6 Red Hat Enterprise Linux Server release 7.6 (Maipo) Oracle Linux Server release 7.6 cpe:/o:oracle:linux:7:6:server root:[~]# Below is my testing on a freshly installed server. root:[~]# pwd /root root:[~]# ls -lad /root dr-xr-x---. 9 root root 4096 Aug 16 22:07 /root root:[~]# mkdir test root:[~]# ls -lad test drwxr-xr-x. 2 root root 4096 Aug 16 22:07 test root:[~]# root:[~]# useradd a root:[~]# passwd a Changing password for user a. New password: BAD PASSWORD: The password is a palindrome Retype new password: passwd: all authentication tokens updated successfully. root:[~]# chmod u+s test root:[~]# root:[~]# su - a [a@localhost ~]$ cd /root/test -bash: cd: /root/test: Permission denied [a@localhost ~]$ cd /root -bash: cd: /root: Permission denied [a@localhost ~]$ logout root:[~]# root:[~]# ls -lad /root dr-xr-x---. 10 root root 4096 Aug 16 22:07 /root root:[~]# chmod o+x /root root:[~]# root:[~]# su - a Last login: Fri Aug 16 22:08:54 CST 2019 on pts/0 [a@localhost ~]$ cd /root/test [a@localhost test]$ [a@localhost test]$ pwd /root/test [a@localhost test]$ ls -la . total 8 drwsr-xr-x. 2 root root 4096 Aug 16 22:07 . dr-xr-x--x. 10 root root 4096 Aug 16 22:07 .. [a@localhost test]$ touch file1 touch: cannot touch ‘file1’: Permission denied [a@localhost test]$ logout root:[~]# root:[~]# chmod o+w test/ root:[~]# root:[~]# su - a Last login: Fri Aug 16 22:09:31 CST 2019 on pts/0 [a@localhost ~]$ [a@localhost ~]$ cd /root/test [a@localhost test]$ touch file1 [a@localhost test]$ ls -la total 8 drwsr-xrwx. 2 root root 4096 Aug 16 22:11 . dr-xr-x--x. 10 root root 4096 Aug 16 22:07 .. -rw-rw-r--. 1 a a 0 Aug 16 22:11 file1 [a@localhost test]$ mkdir folder1 [a@localhost test]$ ls -la total 12 drwsr-xrwx. 3 root root 4096 Aug 16 22:11 . dr-xr-x--x. 10 root root 4096 Aug 16 22:07 .. -rw-rw-r--. 1 a a 0 Aug 16 22:11 file1 drwxrwxr-x. 2 a a 4096 Aug 16 22:11 folder1 [a@localhost test]$ As you can see, it seems the files and folders the user a created in /root/test didn't inherit the owner and group of it. The owner and group is a and not root. Are there any problems with my testing? I'm new in Linux.

The core of the topic is a very a common but I am not satisfied. I have a script looking for a pid and running the kill command on the pid if found. So I chown the script to root.root and add 4755 as suid. The script should now run with root privileges, right? Nope. I stumbled over a nice explanatory article explaining why it ain't working due to security reasons See Vidar's Blog here Is there a way to achieve the a code like kill -9 3385 in the context of root? Could an approach be to invoke a child script that has the required privileges?

I am having a C executable in AIX system by which I can run the command through any user like root or system users. script having below permissions. On AIX server lrwsrwxrwx 1 root system 24 Mar 2016 /var/srty/bin/switchuseridprogram -> /opt/switchuseridprogram -rwsr-sr-x 1 root mrc 5024 Jul 20 2015 /opt/switchuseridprogram Example usage /var/srty/bin/switchuseridprogram root 'chown mtest1:dba /mprt/setup/test.log' Now I am preparing one RHEL system and I don't have source code of that C executable, and I want to use the same functionality in that RHEL system without using sudo. How to do it?

On Unixes (including Gnu/Linux) suid/sgid (or file capabilities) is the only, native (all other ways use this way), way to escalate privileges. As a sysadmin, I like to write scripts as they are easy, and well adated to the task. **However suid and sgid is not honoured for scripts and other interpreted languages.** Therefore I would like to find some alternatives. (I don't mind general solutions, or special cases).