According to Warner Losh:
>
>and loadable device drivers....
>
>However, it would be trivial to mark a process as chroot and then
>check the set[gu]id bits at exec time. 

Yeah but you still don't prevent a set[gu]id file being set up within
the jail and being executed outside the jail.  This is the point I
keep trying to make - when you are in the jail the world is a
different place.  Things that pay attention to file system state (such
as, set[ug]id binaries) are can be used in an attack by crafting a chroot
environment , setting up some files and then running those files
outside the chroot'ed environment.  If you allow users to run chroot
then you must ensure that there is no ability to change their [ug]id
within the chroot.


>Ignoring set[gu]id bits on exec would certainly be sufficient for
>things like tar doing a chroot to get around some security problems
>that were discussed in bugtraq recently (which started this whole
>thread, iirc).  However, I don't know if it would compromise the
>system in other ways.
>

You, and others, are concentrating on

a) the binaries will just be run from within the chroot area.  This
need not be the case.

b) you need to get root to compromise the system - another uid can be
just as useful, either as a tool to get root or as an end in itself.

Allowing users to chroot without carefully considering the
implications of this both within & outside of the chrooted area is
going to be a major problem.

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