Re: [Boost-build] security: install rule links target in destination?

Subject: Re: [Boost-build] security: install rule links target in destination?
From: Roman Neuhauser (neuhauser_at_[hidden])
Date: 2009-12-23 22:09:44

# ghost_at_[hidden] / 2009-12-23 21:43:48 +0300:
> On Wednesday 23 December 2009 21:07:58 Roman Neuhauser wrote:

> > Running "bjam install" with insufficient privileges revealed interesting
> > behavior: it appears bjam runs ld on /usr/local/bin/maildirs:
> > 
> > gcc.link /usr/local/bin/maildirs
> > /usr/bin/ld: cannot open output file /usr/local/bin/maildirs: Permission denied
> > 
> >     "g++" -L"/usr/local/lib"  -Wl,-rpath-link -Wl,"/usr/local/lib" -o "/usr/local/bin/maildirs" -Wl,--start-group "bin/gcc-4.2.1/release/maildirs.o"  -Wl,-Bstatic  -Wl,-Bdynamic -lboost_filesystem -Wl,--end-group -Wl,--strip-all
> > 
> > 
> > ...failed gcc.link /usr/local/bin/maildirs...
> > 
> > Security-wise, this is really undesirable.  The install stage must not
> > do more than copy files. 
> 
> Roman,
> 
> what security problems do you see? Are you worried about running the
> compiler as root user?

Somewhat.  Call me paranoid but shit happens; see also ./configure
trojans (http://www.openbsd.org/porting/autoconf.html).  The compiler
suite doesn't need to run as root to build this project and the program
will never run as root either, so why tease the devil?

> > Am I doing something wrong in the Jamroot, or is this "normal"? 
> 
> This is normal. For development, the 'maildirs' binary has rpath to the
> location of 'bfs' library (and other dependency libraries), so that
> running the binary just work. When installing, such hardcoding of
> rpaths is generally not desirable, so we relink the binary.

I'm doing this on FreeBSD.  This operating system differs from Linux in
that /usr houses only the base operating system, packages go into /usr/local.
However, for whatever reason, /usr/local/lib is not searched by the runtime
linker.

The 'bfs' library is in fact /usr/local/libboost_filesystem.so; in bbv2
parlance it's a "prebuilt library".  There are no libraries built as
part of the project.  Whether the program runs from the build directory
or in the install path, it needs to have "-Wl,-rpath /usr/local/lib",
and as ldd shows, that's indeed the case:

roman_at_isis ~/codex/maildirs 1216:1 > ldd bin/gcc-4.2.1/release/maildirs
bin/gcc-4.2.1/release/maildirs:
        libboost_filesystem.so => /usr/local/lib/libboost_filesystem.so (0x28097000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280aa000)
        libm.so.5 => /lib/libm.so.5 (0x2819e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281b8000)
        libc.so.7 => /lib/libc.so.7 (0x281c3000)
        libboost_system.so => /usr/local/lib/libboost_system.so (0x282da000)
        libthr.so.3 => /lib/libthr.so.3 (0x282de000)
roman_at_isis ~/codex/maildirs 1217:0 > ldd =maildirs
/usr/local/bin/maildirs:
        libboost_filesystem.so => /usr/local/lib/libboost_filesystem.so (0x28097000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280aa000)
        libm.so.5 => /lib/libm.so.5 (0x2819e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281b8000)
        libc.so.7 => /lib/libc.so.7 (0x281c3000)
        libboost_system.so => /usr/local/lib/libboost_system.so (0x282da000)
        libthr.so.3 => /lib/libthr.so.3 (0x282de000)

Looks like the relink is gratuitous in the case of this project.

> If you set the 'hardcode-dll-paths' to 'false' then the relink should not
> happen.

I changed the rule to

exe maildirs
    : maildirs.cpp bfs
    : <include>/usr/local/include
      <hardcode-dll-paths>false
;

but see no change in behavior.  Can you please point out my mistake?

> But on the other hand, it will be inconvenient to run the binaries
> in the build tree.

That's only true if the program uses a dynamic library built as part of
the project (minor point).

More importantly: as I see it, this is trading minor maintainer
convenience for user safety.  That seems to me like a bad deal for any
project that has at least one user.

> Some other build systems work in the same way, so presumably there's no better
> solution.

Well, popularity is rarely a proof of quality. ;)

Judging from the stuff I install the most popular build system in open
source software for unix-like systems is make.  It has its warts but one
thing you can generally count on is that when "make all" is done, you
have the "real thing".

> Can you suggest something?

LD_LIBRARY_PATH is a bit less convenient than "it just runs", but IMO
still preferable.  Keep in mind that it's less convenient only for the
maintainer(s), who are typically a miniscule minority of people who
build and install the software.  Both maintainers and users mostly run 
uninstalled software to excercise unit and/or regression tests.  This
stuff is by definition automated, so LD_LIBRARY_PATH is a onetime
nuisance.  For example:

check: pure
        @ $(LD_LIB_PATH)=".:$$$(LD_LIB_PATH)" \
          PURELIB=$(srcdir)/lib \
          PURE_INCLUDE=$(srcdir)/test \
          $(srcdir)/run-tests $(notdir $(tests))

Basically, I'd like to recreate the behavior of this Makefile fragment:

LDFLAGS=-Wl,-s -Wl,-L $(LCXXRT) -Wl,-rpath $(RCXXRT) -Wl,-L $(_BOOST)/lib
LCXXRT=$(_CXXRT)
RCXXRT=$(_CXXRT)
LDLIBS=-lboost_filesystem

-- 
Roman Neuhauser