OpenSSH Trojan

Richard Lightman richard at nezumi.plus.com
Fri Aug 2 02:38:14 PDT 2002


* Dan Eriksen <eriksen at canada.com> [2002-08-02 09:20]:
> On 01 Aug 2002 19:07:48 -0500
> Paul Roberts <dagmar at speakeasy.net> wrote:
> 
> > make DESTDIR=~/reloc install
> 
> 	Excellent. Something like this is so simple, why wouldn't it be mentioned in the LFS book? Even just a note. Or did I just miss it?
> 	I should have done more searching for general-security type info like this, but I mostly found docs that talked about locking down servers and some rather difficult (massively inconvenient) practices. This should be part of the configure, make, make install routine IMHO.
> 
Regretably it is not always that easy, although IMarrogantO it is worth
the trouble finding out what is going on. Some packages use a different
name (eg cups uses BUILDROOT). Some packages have no equivilant of
DESTDIR, but you can overide prefix, PREFIX, or something like that to
get the same results (bin86, bitchx). Some packages just miss a bit
eg for db, after configure:

sed -e 's@^\(docdir=\).*@\1 \${DESTDIR}/usr/share/doc/db@' Makefile >makefile

Some packages assume the install directories are already there (db
again), so you must:

mkdir -p $install/${prefix:-/usr}/{lib,bin,share/doc,include}

Try to keep the destination directory secret until you get to
'make install', otherwise some packages will look for their
configuartion and data files in DESTDIR. A few are 'helpful' enough to
recompile themselves during 'make install' to include the wrong path.

Several packages are smart enough not to overwrite existing
configuration files, but a few look for them in DESTDIR! Some programs
try to install themselves as a certain user, and think that setting the
default user to root is in some way useful. These not a bit of extra
fixing. All suid programs must have their permissions set by hand (but
I think this is an advantage).

I install everything via DESTDIR (or some equivilant) and I would be
happy for the book to do the same. Unfortunately it would require lots
of effort, and unless lots of people speak up now and agree with me,
I can understand that it is not a high priority.

Richard
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message



More information about the lfs-security mailing list