> >>>> Sebastian 'lunar' Wiesner <basti.wiesner@[...].net> (SW) wrote:

> SW> I don't see a problem with SUID on scripts. If you restrict write access
> SW> to the owner, modification is hardly possible. 
> SW> However, if you allow world-wide write access to your binaries and
> SW> scripts, both can easily be modified...

The scenario is as follows: Suppose the script starts with the line:
#!/usr/bin/python

(using #!/usr/bin/env python would be disastrous because the user could
supply his own `python interpreter' in his PATH.)

Now a malicious user can make a link to this file in his own directory,
e.g. to /Users/eve/myscript1. Because permissions are part of the file
(inode), not of the file name, this one is also suid.

Now she execs /Users/eve/myscript1. The kernel, when honoring suid scripts,
would startup python with effective uid root with the command line:
/usr/bin/env /Users/eve/myscript1

Now in another process eve changes the link /Users/eve/myscript1 to
point to another script /Users/eve/myscript2. If she manages to change the
link between the startup of the python executable and the interpreter
opening the file /Users/eve/myscript1, she has her own script running as
root.

Of course the timing is a bit critical but if you try often enough some
time it will succeed. The problem is the time window between starting the
executable and opening the script. There is no guarantee that the file will
be the same. It can only be made safe if interpreters can be passed inodes
or opened files by the kernel, but that is not how most interpreters work.
At least not python.
-- 
Piet van Oostrum <piet@[...].nl> 
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@[...].org
-- 
http://mail.python.org/mailman/listinfo/python-list