der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:

> >> Yeah...I tend to use chroot(8) to do the chroot, then have a tiny
> >> program in the new root that does setuid() and execs [...]
> > chroot(8) is fundamentally broken, as it requires the executable to
> > be inside the jail.
> 
> How is that "fundamentally broken"?  It's still plenty useful.  It's
> useful for "chroot /trialroot /bin/sh", it's useful for what I want (if
> I cared enough, my tiny executable would be outside the jail, and would
> do the chroot(2) itself, rather than depending on chroot(8))....

True -- I was only talking from a seucrity view point. There's also
the problem of shared libraries. One solution I submitted to the
FreeBSD project over a year ago, was a 4 line patch to ld.so, that
simply groked LD_CHROOT (one could also add LD_CHROOT_UID and
LD_CHROOT_GID), and chrooted after dynamic linking was complete. This
permits the executable, ld.so and shared-libs to be outside the
chroot-jail,(which has not only security benefits, but takes advantage
of shared memory, disk-space reduction, ease-of-use etc). Starting up
a chrooted daemon is then as simple as

	# export LD_CHROOT=/newroot;
	# named (etc)

Paul-Henning Kamp (FreeBSD core) personally nuked this patch, using
the most incredible fatuous arguments, from stating the patch would
slow down ld.so, to that one could gain the same memory-disk benefits
by simply hardlinking your system libraries into the chrooted
area... The mind boggles.

From: Julian Assange <proff@iq.org>
Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments
To: phk@critter.dk.tfs.com (Poul-Henning Kamp)
Cc: security@freebsd.org, hackers@freebsd.org
Date: Sun, 23 Feb 1997 18:54:22 +1100 (EST)

> >: >I have read it twice now, to be quite honest, this sort of change scares 
> >: >the hell out of me.  It seems like it'd be real easy to make a mondo 
> >: >security hole out of it due to the usual chroot() risks.

No, it has the same protection that LD_PRELOAD does.

> >I took a quick peek at it while looking for other security problems,
> 
> Considering the way shared libs work, I would not trust a program in
> a chroot sandbox to use the shlibs I use outside.  This does >not<
> in any way improve security.

The only way to break out of the sandbox into the shlib image is
if the vm system is broken and permits mprotect() transition to
PROT_WRITE/MAP_SHARED of the shlib code area, which was opened as RDONLY and
mapped PROT_READ/MAP_COPY.

mmap.2 ->

     [EACCES]      The flag PROT_READ was specified as part of the prot param-
                   eter and fd was not open for reading.  The flags
                   PROT_WRITE, MAP_SHARED and MAP_WRITE were specified as part
                   of the flags and prot parameters and fd was not open for
                   writing.

I haven't tested to see if the vm system is broken. If it is it
must be fixed. Dyson?

> Complication (and slowing down) the shlib startup is not warranted
> by the gain in functionality.

Did you actually look at the patch? It only requires an additional
getenv (not a system call). There are several in ld.so.

        L("LD_LIBRARY_PATH=",           1, &ld_library_path)
        L("LD_PRELOAD=",                1, &ld_preload)
        L("LD_IGNORE_MISSING_OBJECTS=", 1, &ld_ignore_missing_objects)
        L("LD_TRACE_LOADED_OBJECTS=",   0, &ld_tracing)
        L("LD_BIND_NOW=",               0, &ld_bind_now)
        L("LD_SUPPRESS_WARNINGS=",      0, &ld_suppress_warnings)
        L("LD_WARN_NON_PURE_CODE=",     0, &ld_warn_non_pure_code)
 
> You can obtain the same savings in disk by hardlinking the copies of
> the shlibs together (since they're probably on the same filesystem anyway.

Oh boy.

> I vote >NO< to this change.

Maybe you should read your signature first ;)

> --
> Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
> http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
> whois: [PHK]                | phk@tfs.com           TRW Financial Systems, Inc.
> Power and ignorance is a disgusting cocktail.

--
Prof. Julian Assange  |If you want to build a ship, don't drum up people
		      |together to collect wood and don't assign them tasks
proff@iq.org          |and work, but rather teach them to long for the endless
proff@gnu.ai.mit.edu  |immensity of the sea. -- Antoine de Saint Exupery