On Mon, 27 Jan 2003, mouss wrote:

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

...which is why chroot() is root-only (for the moment).

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

You mean like changing passwords across NIS (modulo the fact that they are
sent cleartext on the local wire).

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

You're forgetting about the original problem:  What if you have a
writeable directory somewhere on root in which a mortal user could
construct their own system tree?  You don't have to be root to link
a suid binary to an alternate destination.  link() does not clear the
set-id bits that I am aware of (and a good thing, too -- want to run
'su'?  OOPS!  Just cleared the setuid bit.).

...and login is still setuid?!?  Why?  [Brain infarction, on my part, here
-- why does anybody want to call login directly from a terminal?]

[m: >and the ancient ones chose to put the barrier of protection at the point of
[m: >chroot()ing, and declare that one needed to be root in order to do it.
[m:
[m: This is probably a solution, but not for the problem!

...and which problem are you finding for which restricted chroot() is not
the proper solution for the time being?

[m: I don't see a problem either. I won't even see a problem if chroot
[m: didn't exist. just require that people write the right progs with no
[m: security holes and we're ok. The problem is that life is life (lala
[m: lalala)... so now we're having a chroot. why would it be restricted to
[m: root?

chroot is more than just a restrictive jail; it is also useful for
running tests when one does not wish to subject the current environment
on the machine to said testing.

[m: >Allowing only root to do things in unix does not mean that nobody
[m: >else can do them, it means that people can choose what things to give
[m: >to users as they see fit at their site.
[m:
[m: The problem is that whenever you restrict something to root, as soon
[m: as it is found useful (if it's not, then there's no need to have it at all
[m: say some), there is a need to create a suid prog to allow people to
[m: use it, which is worst than allowing it directly.

I disagree with this.  The reason the suid program is there is to permit
*controlled* access to the secured entry point.  If the suid program were
not there, there would be *no* access to said entry point.  This may be
fine, depending on your preferred MO.  I have no need for a user-level
chroot to run at the moment.  I might need it somewhere down the line.

[m:
[m: >                                     Think of all the variations on the
[m: > /etc/passwd
[m: >swap that we have been discussing, and all of the bait-&-switch tricks that
[m: >allowing any old user to chroot arbitrarily can cause. Then think of all
[m: >the uses for users chrooting at will, and i think only a few very special
[m: >cases will not be served by someone just putting a setuid binary that can
[m: >chroot for you. and, speaking of that, such a command already exists, and
[m: >it is called chroot. Modifying this command for a local site's needs to allow
[m: >it to be safely run setuid is up to individual sites to do as they see
[m: >fit, typically this would involve either a priori or at runtime verification
[m: >that there werent e.g. setuid root binaries in the chroot()ed tree, or
[m: >similar hazards.
[m:
[m: I understand the problem, but believe the solution isn't chroot restriction

I believe the chroot() restriction is addressing a different problem than
you have in mind.

[m: cheers,
[m: mouss
[m:
[m:


				--*greywolf;
--
My other computer runs NetBSD.