At 13:12 27/01/2003 -0500, Lord Isildur wrote:
>but it is not a case of a process gaining root privs incorrectly;

If a process gains privileges, then it is probably (it's doing what it wants).
the incorrectness is at the system level.

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

well, I'd stop here for a second. just because these setuid/chroot/...
problem has not received a definitive answer because of the design of Unix
does not mean one approach is legitimate.

There are other ways to achieve the setuid things. for example, to change
passwords, one can use a client server program, where the server runs as root
and a user uses a client to change his passwd. Of course care must be taken,
but without a lot of calculation, one can certainly prove you can do it 
with at least
the same level of security. etc.

Anyway, it should not be possible for a program to use setuid progs (be that
login or anything) to gain privileges they don't have. Otherwise be sure 
someone
will find the hole even if you hide it. It should be defeated by design, 
not by luck.
If "login" is copied somewhere, it loses its suid flags. so no one should 
become
superuser using any passwd file. If root copies "login" and makes it suid,
then it's root's decision, and in unix, root is root... He can allow you to 
boot
a new kernel where the uid checks have been removed, so...


>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 is probably a solution, but not for the problem!

>[snip]
>I don't see a problem with only root being andle to chroot. it is always
>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 don't see a problem either. I won't even see a problem if chroot didn't
exist. just require that people write the right progs with no security holes
and we're ok. The problem is that life is life (lala lalala)...
so now we're having a chroot. why would it be restricted to root?


>Allowing only root to do things in unix does not mean that nobody else
>can do them, it means that people can choose what things to give to users
>as they see fit at their site.

The problem is that whenever you restrict something to root, as soon
as it is found useful (if it's not, then there's no need to have it at all
say some), there is a need to create a suid prog to allow people to
use it, which is worst than allowing it directly.

>                                     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. Then think of all
>the uses for users chrooting at will, and i think only a few very special
>cases will not be served by someone just putting a setuid binary that can
>chroot for you. and, speaking of that, such a command already exists, and
>it is called chroot. Modifying this command for a local site's needs to allow
>it to be safely run setuid is up to individual sites to do as they see
>fit, typically this would involve either a priori or at runtime verification
>that there werent e.g. setuid root binaries in the chroot()ed tree, or
>similar hazards.

I understand the problem, but believe the solution isn't chroot restriction

cheers,
mouss