Subject: Re: chroot(2)/LD_CHROOT
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Julian Assange <email@example.com>
Date: 10/13/1998 01:46:18
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 <firstname.lastname@example.org>
Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments
To: email@example.com (Poul-Henning Kamp)
Cc: firstname.lastname@example.org, email@example.com
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
[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
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.
> 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 | firstname.lastname@example.org Private mailbox.
> whois: [PHK] | email@example.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
firstname.lastname@example.org |and work, but rather teach them to long for the endless
email@example.com |immensity of the sea. -- Antoine de Saint Exupery