Matthew Seaman wrote:
[EMAIL PROTECTED] 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
