> There seem to be some involved in this debate who want to make it
> easy for people to write setuid programs that are safe - that's an
> insane desire, there's no point even attempting it.  Writing setuid
> programs has always been hard, and will always be hard.

The Greg Woods position is in fact pretty out there.  He wants it to
be possible to get setuid programs into a state where they can perform
filesystem operations using the saved ID but can't execute an
arbitrary program with that ID.  Ergo, even if such a program had
buffer overflow vulnerabilities, it couldn't be exploited to get a
root shell--or so goes the theory.  It's easy to see what's wrong with
this picture.

When I pointed out that you could simply chmod /bin/sh setuid and get
your root shell anyway, he said, "Oh, right, I forgot!  We also have
to turn off the ability to set the setuid bit using the saved ID."
I'm sure I could point out that such a program could get a root shell
by creating a root crontab entry to chmod u+s /bin/sh in the very near
future, and he'd come up with same piece of duct tape for that, too.
And so on.  If you have root on the local filesystem, you'll have root
on the machine in a very small number of steps, complicated Rebus
contraptions to the contrary notwithstanding.