On Thursday 23 July 2009 07:00:58 per...@pluto.rain.com wrote: > DarkSoul <darks...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"