According to Eduardo E. Horvath:
>
>How is a user going to manage to install a set-uid or set-gid binary
>without superuser privileges?  (I suppose he can make this set-uid or
>set-gid to his own account but I have difficulty seeing how this
>compromises system security.)

I suppose it all hinges on how carefully we can control the concept of
"his own account".  This control is normally vested in files that only
root has privilege to modify, with a chrooted environment the control
of those files will be under the control of a user - once those files
are chrooted their meanings are very different.

>  All the standard methods for breeching root
>are disabled: su doesn't work, login doesn't work, any of the
>stack-overflow attacks don't work because those executables, even if they
>could be accessed from inside the chroot jail would simply no longer
>acquire root privilege themselves so compromising them will simply give
>the user access to his own account.

Accepted but I find the constant reference to root a bit disconcerting
and is why I re-opened this particular can-o-worms.  I saw a lot of
code fragments & statements that only checked for the root uid.  I
believe that this is a bit of a blind spot.  I just wanted to point
out that you need to do more than protect against a direct grab at
root, you need to take care that the creds that the user entered the
jail with are not changed in any way or manner.  If you don't do this
you will find someone becoming bin or surfing /dev/kmem or even just
becoming your web admin and "helping out" with the web pages.

-- 
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================
  And the monks would cry unto them, "Keep the bloody noise down!"
  - Mort, Terry Pratchett.