1

This is related to this question.

I have a script (fix-permissions.sh) that fixes some file permissions:

#! /bin/bash 
sudo chown -R person:group /path/
sudo chmod -R g+rw /path/

And a small c program to run this, which is setuided:

#include "sys/types.h"
#include "unistd.h"
int main(){
    setuid(geteuid());
    return system("/path/fix-permissions.sh");
}

Directory:

-rwsr-xr-x  1 root  root  7228 Feb 19 17:33 fix-permissions
-rwx--x--x  1 root  root   112 Feb 19 13:38 fix-permissions.sh

If I do this, everything seems fine, and the permissions do get correctly fixed:

       james $ sudo su someone-else
someone-else $ ./fix-permissions

but if I use strace, I get:

someone-else $ strace ./fix-permissions
/bin/bash: /path/fix-permissions.sh: Permission denied

It's interesting to note that I get the same permission denied error with an identical setup (permissions, c program), but a different script, even when not using strace. Is this some kind of heureustic magic behaviour in setuid that I'm uncovering?

How should I figure out what's going on?

System is Ubuntu 10.04.2 LTS, Linux 2.6.32.26-kvm-i386-20101122 #1 SMP

Community
  • 1
James
  • 280
  • 2
  • 11

1 Answers1

4

Linux ignores the setuid bit when running a process under strace or similar programs.

  • Linux-Kernel mailing list, Re: 2.4.16 + strace 4.4 + setuid programs:

    From: Manfred Spraul
    Date: Thu Dec 06 2001 - 12:25:53 EST

    If you want to strace setuid things and have the setuid bit honored, you have to run strace as root with the -u option.

    No, even that's not possible anymore. setuid is now always ignored if a process is ptraced, even if root is ptracing - that's the fix for the latest ptrace root exploit (2.4.1x).

which is probably talking about:

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Okay, so in summary: `setuid` has so many security holes that I just shouldn't expect it to work, and ever using it ever is a very bad idea? – James Feb 20 '11 at 19:01
  • @Autopulated: No. My post only describes *one* exploit, from 2003, not "many". And it is *careless use* of setuid, not the feature itself, that leads to security holes. Carefully written programs work fine. It is best to avoid setuid, however, , and *especially* in your "Gmail password" case (for which I have suggested a different solution). – u1686_grawity Feb 20 '11 at 19:26