Subversion Repositories svn LFS-FR

Compare Revisions

Regard whitespace Rev 1345 → Rev 1344

0,0 → 1,16
# L'option '-N' de patch est supprimée car elle supporte des correctifs
# cassés (voir la page de manuel patch(1) ).
# Installation des pages de manuel et info dans le répertoire objet, afin qu'ils
# ne soient pas installés dans /tools, avec --infodir=$(pwd)/DESTDIR
# --mandir=$(pwd)/DESTDIR, ou avec tout autre procédé.
# Support d'un x86_32 et x86_64 natif. Pas de multilib, de compilation croisée,
# ou d'émulation.
# Contactez la liste de diffusion si vous voulez aider à ajouter le support de
# davantage de plateformes.
# Ajout de plusieurs petits changements aux outils, nécessaires pour démarrer
# le système temporaire. Ces changements ont été apportés à e2fsprogs, sysvinit,
# udev et util-linux. Ajout du répertoire booting_temporary et des pages.
0,0 → 1,36
# Le correctif issetugid() de Glibc n'est plus utilisé. issetugid() pouvait
# être préchargé à partir d'une bibliothèque définie par l'utilisateur, comme
# getuid() ou getgid(), donc issetugid() n'a aucun avantage. Dans BSD et solaris,
# issetugid() est un syscall du noyau et est plus sûre. Avec Linux, nous
# devrions utiliser __libc_enable_secure(), qui est équivalent,
# mais qui exige des paquets pour être corrigée. On devrait rechercher la
# fonction issetugid() de tous les paquets, laquelle devrait être remplacée par
# __libc_enable_secure().
# Object directories are used whenever possible, to support building from
# read-only sources. One day this may be usefull, such as building from source
# which were unpacked on to a cdrom, or read-only partition.
# In tools we don't let packages install to /tools/libexec/, for consistancy.
# Avoid installing docs to /tools, since we're not going to use them.
# It would be nice to optionally strip packages as they're installed.
# Bison, Flex, and M4, are needed when using snapshots of GCC (or Binutils).
# Everything in /tools is hardened so that we reboot into a hardened system.
# The --fatal-warnings linker option is used primarily for locating
# DT_TEXTREL, with --warn-shared-textrel, but also causes compiler errors
# when mktemp(3) or tmpnam(3) are used... so we have zero tolerance for these.
# Whatever bug fix patches are normally used in Chap6, we use them in /tools,
# because we're going to reboot /tools.
# When package maintainers offer a GnuPG signature, or md5/sha, file, then
# use that instead of making our own md5sum.
# Don't install anything to /tools/sbin, since only the administrator uses
# /tools there is no need to have another directory for admin applications.
0,0 → 1,85
This page needs to add additional information about what is needed to get the
Glibc test suite to pass, such as the SysV module.
Enable extended attributes for your file system, for file system Posix
capabilities, Access Control Lists, and security markings:
Enable Linux capabilities, and filesystem capabilities:
Enable Loop-AES for encrypted swap:
All the Grsec and PaX options can be enabled, but some should be disabled for
the best security.
Do _NOT_ enable the following (we don't need, or use, them):
The SOFTMODE means settings will not be enforced; this is for curious users or
for debugging problems. EI_PAX is for supporting legacy markings which we do
not have (see below). PAX_EMUTRAMP is usefull for Glibc's localedef if it is
not modified, but in general the PAX_EMUTRAMP option should be avoided if
possible. These three options reduce security.
Do enable the following:
This option tells the PaX kernel that we have PaX elf header markings, which
are placed by our patched version of Binutils. This is the preferred method
which replaces EI_PAX.
Under "Grsecurity -> Executable Protections -> Trusted Path Execution" you may
want to enable:
This option enables 'Trusted Path Execution'. Like the help says, this option
is used to restrict which programs users can run depending on the program
ownership and permissions. This can disallow users from running programs they
build or install.
Most administrators will not want to enable this option. This slightly loosens
the 'Trusted Path Execution' restrictions, allowing users to run thier own
programs, but not programs in another user's directory.
To only allow selected users to run their own programs enable:
Choose the numeric GID for your trusted group. Users in this group will be able
to run programs that are not in a directory owned by root, or programs that are
world or group writtable. Generally this means these users can run their own
programs. If you compile software as a non-root user, then that user will need
to be added to this group. Alternately you could set this to GID 0, and add
your trusted users to the root group. Otherwise you will probably need to run
something like groupadd -g 1005 trusted.
If you plan to use the X11 windowing system, then the options
CONFIG_GRKERNSEC_KMEM and CONFIG_GRKERNSEC_IO, in the Grsecurity "Address Space
Protection" menu, should be disabled. See the help for those options for more
Be warned that the CONFIG_GRKERNSEC_IO option, which disallows modifying the
kernel in memory while its loaded, breaks pnpdump(8) from Isatools.
All the rest of the options will increase system security.
The kernel will build with -D_FORTIFY_SOURCE=2, and will disable SSP
automatically. There is a performance penalty when building the kernel with
-D_FORTIFY_SOURCE=2, which can be disabled by building with make
0,0 → 1,106
# Bash $RANDOM patch:
# Bash upstream fixes:
# wget -np -nd -m -A "bash41-*" -P bash-4.1-patches
# Binutils PT_PaX patch:
# Binutils PT_PaX testsuite fix patch:
# Cross LFS Bootscripts temporary tools patch
# Diffutils better tmp patch:
# Expect Spawn patch:
# Expect TCL patch:
# Flex GCC44 fix patch:
# Gawk libsigsegv patch:
# GCC -fPIE patch:
# GCC -fstack-protector-all patch:
# Gettext upstream fixes:
# Glibc branch update patches:
# Glibc localedef trampoline patch:
# Glibc random mk*temp() patch:
# Glibc PT_PaX patch:
# Glibc res_randomid() patch:
# Glibc sanitize environment patch:
# Broken - FIXME
# Glibc strlcpy()/strlcat() patch:
# Grsecurity patch:
# Grub patches:
# Gzip better tmp patch:
# Gzip CVE 2006-4337 vilnerability fix:
# Gzip CVE 2006-4338 vilnerability fix:
# Linux frandom patch:
# Broken - FIXME
# Loop-AES patch:
# MPFR branch update patch:
# wget --output-document=mpfr-2.4.2-branch_update.diff
# Patch mkstemp() patch:
# Util-linux-ng Loop-AES patch:
0,0 → 1,137
# Bash:
# Binutils:
# Bison:
# Bzip2:
# md5:3c15a0c8d1d3ee1c46a1634d00617b1a
# Cross LFS Bootscripts
# Coreutils:
# DejaGNU:
# Diffutils:
# E2fsprogs:
# Findutils:
# Flex:
# md5:10714e50cea54dc7a227e3eddcd44d57
# Gawk:
# GCC-4.2 snapshot:
# Gettext:
# Glibc:
# GMP:
# Grep:
# Grub:
# Gzip:
# Linux kernel:
# M4:
# Make:
# Module-init-tools:
# Ncurses:
# Patch:
# Perl:
# Sed:
# Sysvinit:
# Tar:
# TCL:
# Texinfo:
# Udev:
# Util-linux-ng:
# XZ Utils:
# Zlib:
# md5:ab5fa664b51eaa0788fd057c41a09dbd
0,0 → 1,73
Onward branch:
October 4rth, 2008
Hardened LinuxFromScratch was born on the lfs-security mailing list in late
2003. The philosophy is based on learning, one step at a time,
how to harden a Linux system. This was something that was traditionally left
to someone else, such as Hardened Gentoo
(, Owl Linux
(, OpenBSD (, and others.
This was unsatisfying to a do-it-yourselfer, and so Hardened LinuxFromScratch
The ProPolice and PIE LFS hints paved the way, and it became apparent that a
new book was more practical than following multiple LFS hints.
The majority of changes and additions were to the toolchain (GCC, Binutils,
the C library, and the Linux kernel), and how packages were compiled. Although
it is part of the scope of Hardened LinuxFromScratch, the setup of packages
(especially network) has been neglected. In general HLFS has taken the
initiative, when feasible, to fix system vulnerabilities, and is not following
or directed by any outside project.
Unlike distributions who have to maintain reverse compatibility, HLFS is from
scratch and can redesign itself at any time, if there's a reason to. This
advantage has been embraced. Anything can be removed, changed, or added,
without regard to previous versions, because each build is bootstrapped.
A stable version of the book has been in reach several times, but has always
been pushed aside for further advancement and new features. Since 2003, Stack
Smashing Protector (, PaX
( compliance, Grsecurity
(, run-time string buffer overflow detection
(, Linux Posix
(, and
various other additions have been integrated to the build.
During 2008 the Linux kernel added file attributes for posix capabilities,
which were integrated with HLFS (in the Shadow package). This caused a
dependency on a new kernel, and was adopted as an opportunity to eliminate
host system dependencies by adding a reboot after the temporary tools are
installed. In turn, this added complications. An html book could not be read
without an html viewer in the rebooted system, so a simpler solution was plain
text. A plain text book can be run as shell scripts for convenience.
Additionally, both LFS and HLFS have come to recognize that it is unacceptable
for package management to be completely neglected. From the standpoint of HLFS,
this issue is with file management, rather than package management, but the
two are closely related. A responsible administrator should account for each
file, where it came from, and what its purpose is. Furthermore, with posix
capabilities, it is more secure if root does not own any files on the system,
because a process running as root without the FOWNER capability would be
unable to overwrite files not owned by root, and this would make it more
difficult for root to be exploited.
A two user package/file management system was found to be the most practical
solution. This means new packages are installed by an admin-helper. The
package's installed files are recorded, and the ownership is changed to the
admin. This stops new packages from overwriting the files of another package,
allows us to catalog installed package files (so ownership can be reverted for
upgrades), and disallows root from modifying them without the FOWNER
capability. A multi-user package management system (such as the
more_control_and_pkg_man.txt LFS hint) was found to be overly complicated,
and has no advantage over the two user system.
More recently, chroot additions are being considered where ever possible.
As a result of all this, the HLFS book is in a state of change, and has
stopped development of the xml/html book until things become decided. The book
and build system are becoming integrated, and so everything needs to be
thought through before the new Onward branch can be written.