Date: Mon, 11 Feb 2008 11:00:11 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: /usr/local/etc/rc.d/ scripts and non-root user Message-ID: <47B02ABB.1050109@dial.pipex.com> In-Reply-To: <47AEC051.5050808@infracaninophile.co.uk> References: <20080210.033421.6825.0@webmail09.dca.untd.com> <47AEC051.5050808@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman wrote: >gs_stoller@juno.com wrote: > > >>On Wed, 06 Feb 2008, Alex Zbyslaw wrote >> >> >>>Setuid/gid bits on shell scripts aren't considered safe, however and may >>>even be disabled. >>> >>> >>THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE >>FILES (MAKE THEM NOT WRITEABLE). >> >There's no particular reason that setuid bits on scripts are dangerous >nowadays. However in the dim and distant past (before the millenium) >there used to be a race condition on opening files that meant it was >trivial to use a setuid script to get a shell running under the target >UID. The horror of this situation seems to have branded itself so deeply >on the Unix psyche that even now, when that race condition has been >eliminated for many years, there is still a lingering reflex response: >"setuid scripts bad." > > Thanks for the clarification. Serves me right for not adding a disclaimer since I had the feeling this had been fixed; but with security better to err on the side of caution. Haven't need a setuid shell script in 15 years and I think I'll still keep it that way :-) It wasn't the right answer to the OPs original problem, in any case. How about: setuid programs of any kind are dangerous. It's very easy to accidentally allow far more than you originally intended. Look at the effort sshd had to go to with privilege separation and that was from a project where security is the watchword. They still got it wrong for a while. How many setuid root programs gave you root shells because they used "more" at some point? Dim and distant past, maybe, but we all know that history has a habit of repeating itself. Weren't there also tricks you could play with IFS if the script didn't set it? And I'm sure that there was some other race condition to do with ^C in the shell, as well as the file-renaming trick which played on the race condition in the kernel, which BSD has fixed by using a file descriptor. --Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B02ABB.1050109>