On Wed, 11 May 2011 11:59:48 +0200 Jonathan McKeown <j.mcke...@ru.ac.za> wrote: >On Wednesday 11 May 2011 04:19:29 Devin Teske wrote: >> >> The reason that the suid bit doesn't work on scripts (shell, perl, or >> otherwise) is because these are essentially text files that are interpreted >> by their associated interpreter. It is the interpreter itself that must be >> suid. > >I'm pretty sure that's not the case, although I'm open to correction. > >The reason the system ignores the suid bit on a script is because of what >would happen when it's executed: > >1) the script is read from a file called <filename> and the system notices >that it needs to be interpreted by another program. > >2) that program is launched and told to re-open the file named <filename> and >execute its contents with suid privilege. > >The problem is a race condition: there's no guarantee that the filename opened >by the interpreter in step 2 is the same file the user executed in step 1.
Yes, that is basically what happened. It was demonstrated under 4.3BSD that a small program needed to do very little to gain privileges when run by a user who had execute access to a suid shell script. The first time the kernel looked at it, the kernel also noted the permissions, including the suid bit. A small program 1) forks a child that loops, creating a symlink to the suid script, removing the symlink, creating a new symlink of the same name but pointing to /bin/sh, removing the symlink again, and repeating, while 2) the parent loops, trying to run the script via the symlink. If the attempt returns, then that means the script actually got run (no security violation). If the attempt instead returns a prompt, # then it means that after the kernel first looked at the file and got the permission bits, the link was changed to point to /bin/sh, which then got run with the suid root permission. (This actually worked for scripts owned by any uid, so the prompt could be $ with the privileges of whatever non-root uid owned the script.) Most people who reported results of trying this at that time said they had a root shell in less than a second, even on slow (for that era) machines. 8-< This problem was publicly announced but not fixed in 4.3BSD. The recommended workaround, instead, was not to have any suid scripts. I do not know when the change was made in the kernel to block suid permission elevation on executable non-binaries (i.e., scripts). Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"