Subject: Re: chroot: why super-user only?
To: None <firstname.lastname@example.org>
From: David Young <email@example.com>
Date: 01/27/2003 12:52:25
On Mon, Jan 27, 2003 at 01:12:08PM -0500, Lord Isildur wrote:
> but it is not a case of a process gaining root privs incorrectly; it is
> the case of a legitimate setuid binary that is sneakily put into a chroot()ed
> world with a hard link before the chroot() is done, and tricking it by the
> chroot'ed world into looking in a bogus passwd file instead of the
> 'right' one. the trouble is that this is a perfectly legitimate thing to do,
> and the ancient ones chose to put the barrier of protection at the point of
> chroot()ing, and declare that one needed to be root in order to do it.
> this allows those who _have_ privileges to restrict those who havent got
> them, which normally works in favor of sysadmins.
> I don't see a problem with only root being andle to chroot.
It is a problem in UNIX that a program runs with all the privileges of
the user who runs it, privileges to read/write files and devices, to
bind sockets, to occupy slots in the process table, and to use the CPU.
Chroot is an imperfect way to reduce privileges.
It is dangerous that one has to effectively increase privileges, by
running a setuid binary, before one can *decrease* privileges. Witness
historical security exploits involving setuid programs such as su.
> possible with little effort to provide users with a setuid binary that will
> chroot and give them a shell in the chroot'ed world, and also hopefully
> do some checking to validate that theyre chrooting into a safe world.
I am skeptical that safety *validation* is possible:
> Think of all the variations on the /etc/passwd
> swap that we have been discussing, and all of the bait-&-switch tricks that
> allowing any old user to chroot arbitrarily can cause.
What I wonder is how many there are left which nobody has thought
of, yet. =( It is desirable to me that the privileges of a process
are easily enumerated. In UNIX, processes are ordinarily trusted to
exercise a tiny number of countless privileges. Most security exploits
are taking advantage.
David Young OJC Technologies
firstname.lastname@example.org Engineering from the Right Brain
Urbana, IL * (217) 278-3933