[RFC] Add CrackLib to Chapter 6 LFS

Kev Buckley k.buckley at lancaster.ac.uk
Fri Aug 5 02:29:52 PDT 2005

I am not a developer but,

> 6) Currently, CrackLib cannot be integrated into LFS using BLFS
> instructions without adding Linux-PAM also. 

Surely that is a reason for modifying a section of BLFS.

> Even if you simply install the CrackLib package, Shadow would have
> to be recompiled to use the now-installed CrackLib libraries and the
> CRACKLIB_DICTPATH parameter modified in the /etc/login.defs file.

The "Your distro, your rules" mantra seems to break horribly if you
add-in Linux-PAM and CrackLib to LFS. How does someone who doesn't 
want it take it out.

The more you add, the harder it becomes to make it "your distro".

Furthermore, adding extra packages also plants the idea in the mind of
the reader that things aren't "optional" to LFS.

Are there going to be instructions explaining how to leave it out if
"your distro" doesn't want/need it ? If there are, then does it really
need to be in.

One of the main features about LFS I have always found appealing is
that there is so little that can be left out of the "chosen" packages,
if ones wishes to do anything with the LFS systems other than test out
the instructions in the book.

Even the use of *more secure* MD5-sum passwords seems to be there as
part of an "add-on" sed command applied after the shadow packages has
been "installed" and that the savvy reader/installer can ignore if
they wish or by comig to understand the process, add in later.

It strikes me that CrackLib merely there to enforce a policy that 
an installer might wish to see in place, very much an aftermarket 
add-on then.

> 7) See #1. LFS should attempt to provide readers with a stable
> (which it already does) and *secure* system. Adding CrackLib is
> a step in the right direction (one of the biggest things which
> can be done) in securing the system.

LFS already builds a fine stable system from which the reader/installer 
can take it anywhere they wish. If they want to secure it beyond where
the LFS ends, then they can go beyond the LFS and make it more secure.

If LFS is going to be *secure*, then personally I hope you guys get
rid of most of the inetutils clients and stick "OpenSSL" and "OpenSSH"
into LFS, and add "iptables" as well.

Now, I doubt you will but I would be willing to guess that the reasons
many of you would put up for not doing so, will probably be as equally
valid a set of reasons for not adding CrackLib into LFS.

Just my threepen'th.


*  Kevin M. Buckley              e-mail: K.Buckley at lancaster.ac.uk   *
*                                                                    *
*  Systems Administrator                                             *
*  Computer Centre                                                   *
*  Lancaster University          Voice:  +44 (0) 1524 5 93718        *
*  LANCASTER. LA1 4YW            Fax  :  +44 (0) 1524 5 25113        *
*  England.                                                          *
*                                                                    *
*  My PC runs Linux/GNU, you still computing the Bill Gate$' way ?   *

More information about the lfs-dev mailing list