Established method to enable suid scripts?

[Scott Bennett]

     On Wed, 11 May 2011 11:59:48 +0200 Jonathan McKeown <j.mckeown at 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         *
**********************************************************************