On Mon, 12 Oct 1998, Brett Lymn wrote:

> Sorry for jumping in late here but it seems to me that people missed
> an important fact :-)
> 
> According to Eduardo E. Horvath:
> >
> >This seems to be getting complicated.  I figure you can solve the security
> >hole if you prevent any chroot-ed process from acquiring root privileges.
> >
> 
> Sorry, no this is too narrow a view.  If a user in the chrooted tree
> can managed to install a set-uid or set-gid binary and then access
> that binary from outside the chrooted area then your security is
> blown.  Ponder, if you will, the implications of becoming a member of
> the kmem group or the user bin (though a quick look at likely trojan
> horses like `ls' are not feasible on the NetBSD system I looked at
> there may be some havoc one can cause).

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.)  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.  Device nodes that do root privilege
checks inside the kernel would likewise be safe.  The only hole I can
think of would be devices that rely on the permissions on the device node
for maintaining security, and if we ever go to a devfs /dev they will need
to be fixed somehow. 

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me