7.13.1. Installation of the kernel
Building the kernel involves a few steps—configuration,
compilation, and installation. Read the README file in the kernel source tree for
alternative methods to the way this book configures the kernel.
Apply the Grsecurity patch:
zcat ../grsecurity-2.1.11-2.6.24.5-200804211829.patch.gz | patch -Np1
Apply the optional Frandom/Erandom patch:
patch -Np1 -i ../linux-2.6.24.7-frandom-1.patch
Prepare for compilation by running the following command:
make mrproper
This ensures that the kernel tree is absolutely clean. The kernel
team recommends that this command be issued prior to each kernel
compilation. Do not rely on the source tree being clean after
un-tarring.
Configure the kernel via a menu-driven interface. BLFS has some
information regarding particular kernel configuration requirements
of packages outside of LFS at
http://www.linuxfromscratch.org/blfs/view/svn/longindex.html#kernel-config-index:
make menuconfig
Alternatively, make
oldconfig may be more appropriate in some
situations. See the README file for
more information.
If desired, skip kernel configuration by copying the kernel config
file, .config, from the host system
(assuming it is available) to the unpacked linux-2.6.24.7 directory. However, we do not
recommend this option. It is often better to explore all the
configuration menus and create the kernel configuration from
scratch.
All the Grsec and PaX options can be enabled, but some should be
disabled for the best security.
-
Do _NOT_ enable the following:
-
CONFIG_PAX_SOFTMODE
-
CONFIG_PAX_EI_PAX
-
CONFIG_PAX_EMUTRAMP
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:
-
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
otherwise 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'si directory.
-
To only allow selected users to run their own programs
enable:
And then you can 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 details.
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. If you
plan to use this system to rebuild LFS or HLFS again then you
should consider enabling the Grsecurity sysctl option. With the
Grsecurity sysctl option you will be able to enforce all the chroot
jail restrictions during normal operation, and you can disable them
while preforming a Chapter 6 (chroot) build. Some of the chroot
options will disallow mknod and mounts inside a chroot. Almost
everything will be able to build and install with all options
enabled, please report any problems.
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
CC="gcc -U_FORTIFY_SOURCE"
Compile the kernel image and modules:
make
If using kernel modules, an /etc/modprobe.conf file may be needed.
Information pertaining to modules and kernel configuration is
located in Section 7.4,
“Device and Module Handling on an HLFS System” and
in the kernel documentation in the linux-2.6.24.7/Documentation directory. Also,
modprobe.conf(5) may be of interest.
Install the modules, if the kernel configuration uses them:
make modules_install
After kernel compilation is complete, additional steps are required
to complete the installation. Some files need to be copied to the
/boot directory.
The path to the kernel image may vary depending on the platform
being used. The following command assumes an x86 architecture:
cp -v arch/i386/boot/bzImage /boot/hlfskernel-2.6.24.7
System.map is a symbol file for the
kernel. It maps the function entry points of every function in the
kernel API, as well as the addresses of the kernel data structures
for the running kernel. Issue the following command to install the
map file:
cp -v System.map /boot/System.map-2.6.24.7
The kernel configuration file .config
produced by the make
menuconfig step above contains all the
configuration selections for the kernel that was just compiled. It
is a good idea to keep this file for future reference:
cp -v .config /boot/config-2.6.24.7
Install the documentation for the Linux kernel:
install -d /usr/share/doc/linux-2.6.24.7 &&
cp -r Documentation/* /usr/share/doc/linux-2.6.24.7
It is important to note that the files in the kernel source
directory are not owned by root. Whenever a package is unpacked as
user root (like we did
inside chroot), the files have the user and group IDs of whatever
they were on the packager's computer. This is usually not a problem
for any other package to be installed because the source tree is
removed after the installation. However, the Linux source tree is
often retained for a long time. Because of this, there is a chance
that whatever user ID the packager used will be assigned to
somebody on the machine. That person would then have write access
to the kernel source.
If the kernel source tree is going to be retained, run chown -R 0:0 on the linux-2.6.24.7 directory to ensure all files are
owned by user root.
![[Warning]](../images/warning.png)
Warning
Some kernel documentation recommends creating a symlink from
/usr/src/linux pointing to the
kernel source directory. This is specific to kernels prior to the
2.6 series and must not be
created on an LFS system as it can cause problems for packages
you may wish to build once your base LFS system is complete.
Also, the headers in the system's include directory should always be the ones against which Glibc
was compiled, that is, the sanitised headers from the Linux
kernel tarball, and therefore, should never be replaced by the raw kernel
headers.