>>>>> Sebastian 'lunar' Wiesner <[EMAIL PROTECTED]> (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 <[EMAIL PROTECTED]> URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
