Subject: Re: chroot: why super-user only?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <email@example.com>
Date: 01/24/2003 10:12:24
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?