SGID/SUID on scripts

[Jonathan McKeown]

On Thursday 23 July 2009 07:00:58 perryh at pluto.rain.com wrote:
> DarkSoul <darksoul at darkbsd.org> wrote:
> > Anthony Pankov wrote:
> > > SGID/SUID bits don't work with shell scripts, do they?
> >
> > They don't.

[snip description of race condition]

> In principle, it should be possible to fix this exposure by
> improving the interface between execve() and the interpreter:
>
> The execve() syscall already has the script file open to read the
> shebang line.  Leave it open, and ensure that the interpreter
> receives the open descriptor as fd#3 just as 0, 1, and 2 are already
> used for stdin, stdout, and stderr.  An interpreter supporting this
> approach would check whether stdscr (fd#3) is already open, and if
> so read from it instead of open()ing the script file.  This should
> ensure that the script which gets executed is the same inode on
> which execve() saw the SGID/SUID bits set, even if the filesystem
> has been changed by the time the interpreter has gotten started.
> It would be the responsibility of whomever decided to set the
> SGID/SUID bits on a particular script to ensure that the interpreter
> involved supports the mechanism.
>
> I vaguely recall having seen a similar (or even identical) approach
> suggested some years ago.  It may even have been implemented in some
> variant of Un*x.

It's mentioned in the perlsec page of perl's documentation (installed as a 
manpage on FreeBSD), under Security Bugs, which describes the race condition, 
and the same fix (keeping the script open and passing /dev/fd/3 rather than 
closing it and passing the filename). It goes on to say:

> Most modern releases of SysVr4 and BSD 4.4 use this approach to avoid the
> kernel race condition.

Although it would appear not to apply to FreeBSD.

Jonathan