On 23 Jan 2003, Wolfgang S. Rupprecht wrote:

>
>> > You would need to disallow set-id execution (and, arguably, device
>> > access.)
>
>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?

And which password file should it check?  The passwd entries are
coming from wherever /etc/nsswitch.conf says they are (and on a dynamic
nsswitch like solaris you can drop in new backend modules which access
new repositories which may not even be local files).  Even with NetBSD's
current static nsswitch, there's probably nothing to stop you putting an
/etc/nsswitch.conf in the chrooted area which contains

	passwd: nis

And arrange that anything in the chrooted area goes to your own evil NIS
server (which of course provides your own passwd record for root).  OK,
you could check ownership of /etc/nsswitch.conf first...


Roger