On Thu, 23 Jan 2003, der Mouse wrote:

> >>> 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.

How is this an issue if we disalow Set-id on non-root chroot()?

The idea of making chroot usable by non-root has been floated, and everone
has taken the lack of honoring set-id as a given. What else do we need?

Take care,

Bill