Date: Thu, 23 Jul 2009 10:18:01 +0200 From: Jonathan McKeown <j.mckeown@ru.ac.za> To: freebsd-hackers@freebsd.org Subject: Re: SGID/SUID on scripts Message-ID: <200907231018.02032.j.mckeown@ru.ac.za> In-Reply-To: <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com> References: <19939654343.20090722214221@mail.ru> <4A6795E7.7020700@darkbsd.org> <4a67ee8a.wIGNpBr1/a3vNK2S%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 23 July 2009 07:00:58 perryh@pluto.rain.com wrote: > DarkSoul <darksoul@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907231018.02032.j.mckeown>