1
2
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 setuid
ed:
#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
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 – 2011-02-20T19:01:28.127@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). – user1686 – 2011-02-20T19:26:39.430