>>> You would need to disallow set-id execution (and, [...])
> One could claim that /usr/bin/su, being a suid-root program, should
> be quite a bit more paranoid about file ownerships than it is.  If
> su(1) simply refused to run unless the password file(s) was owned by
> root and mode 600, there wouldn't be any spoofing problem.  Or am I
> missing another vulnerability?

You're missing another vulnerability.

Consider a system which has an alternative root area set up on one of
its ordinary-use partitions, so that it can be booted from that drive
in case of disaster to the boot drive.

Suppose this disaster-recovery root area has not had a full set of
passwords installed, and that the root password in it is blank or
otherwise known to the attacker.  ("Who cares what the root password
there is, that's used only for disaster recovery.")  Of course, this
root area has its own copy of su.

Chroot to the alternative root area, run su, install a set-uid hole of
your preference, exit, run it, and you're home free.  Even though the
password database su saw was correctly owned.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B