4. Security

Security takes many forms in a computing environment. After some initial discussion, this chapter gives examples of three different types of security: access, prevention and detection.

Access for users is usually handled by login or an application designed to handle the login function. In this chapter, we show how to enhance login by setting policies with PAM modules. Access via networks can also be secured by policies set by iptables, commonly referred to as a firewall. The Network Security Services (NSS) and Netscape Portable Runtime (NSPR) libraries can be installed and shared among the many applications requiring them. For applications that don’t offer the best security, you can use the Stunnel package to wrap an application daemon inside an SSL tunnel.

Prevention of breaches, like a trojan, are assisted by applications like GnuPG, specifically the ability to confirm signed packages, which recognizes modifications of the tarball after the packager creates it.

Finally, we touch on detection with a package that stores “signatures” of critical files (defined by the administrator) and then regenerates those “signatures” and compares for files that have been changed.

4.1 Vulnerabilities

About vulnerabilities

All software has bugs. Sometimes, a bug can be exploited, for example to allow users to gain enhanced privileges (perhaps gaining a root shell, or simply accessing or deleting other user’s files), or to allow a remote site to crash an application (denial of service), or for theft of data. These bugs are labelled as vulnerabilities.

The main place where vulnerabilities get logged is cve.mitre.org. Unfortunately, many vulnerability numbers (CVE-yyyy-nnnn) are initially only labelled as “reserved” when distributions start issuing fixes. Also, some vulnerabilities apply to particular combinations of configure options, or only apply to old versions of packages which have long since been updated in BLFS.

BLFS differs from distributions—there is no BLFS security team, and the editors only become aware of vulnerabilities after they are public knowledge. Sometimes, a package with a vulnerability will not be updated in the book for a long time. Issues can be logged in the Trac system, which might speed up resolution.

The normal way for BLFS to fix a vulnerability is, ideally, to update the book to a new fixed release of the package. Sometimes that happens even before the vulnerability is public knowledge, so there is no guarantee that it will be shown as a vulnerability fix in the Changelog. Alternatively, a sed command, or a patch taken from a distribution, may be appropriate.

The bottom line is that you are responsible for your own security, and for assessing the potential impact of any problems.

The editors now issue Security Advisories for packages in BLFS (and LFS), which can be found at BLFS Security Advisories, and grade the severity according to what upstream reports, or to what is shown at nvd.nist.gov if that has details.

To keep track of what is being discovered, you may wish to follow the security announcements of one or more distributions. For example, Debian has Debian security. Fedora’s links on security are at the Fedora wiki. Details of Gentoo linux security announcements are discussed at Gentoo security. Finally, the Slackware archives of security announcements are at Slackware security.

The most general English source is perhaps the Full Disclosure Mailing List, but please read the comment on that page. If you use other languages you may prefer other sites such as heise.de (German) or cert.hr (Croatian). These are not linux-specific. There is also a daily update at lwn.net for subscribers (free access to the data after 2 weeks, but their vulnerabilities database at lwn.net/Alerts is unrestricted).

For some packages, subscribing to their ‘announce’ lists will provide prompt news of newer versions.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/vulnerabilities

4.2 make-ca-1.12

Introduction to make-ca

Public Key Infrastructure (PKI) is a method to validate the authenticity of an otherwise unknown entity across untrusted networks. PKI works by establishing a chain of trust, rather than trusting each individual host or entity explicitly. In order for a certificate presented by a remote entity to be trusted, that certificate must present a complete chain of certificates that can be validated using the root certificate of a Certificate Authority (CA) that is trusted by the local machine.

Establishing trust with a CA involves validating things like company address, ownership, contact information, etc., and ensuring that the CA has followed best practices, such as undergoing periodic security audits by independent investigators and maintaining an always available certificate revocation list. This is well outside the scope of BLFS (as it is for most Linux distributions). The certificate store provided here is taken from the Mozilla Foundation, who have established very strict inclusion policies described here.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

make-ca Dependencies

Required

p11-kit-0.24.1 (required at runtime to generate certificate stores from trust anchors)

Optional (runtime)

nss-3.88.1 (to generate a shared NSSDB)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/make-ca

Installation of make-ca

The make-ca script will download and process the certificates included in the certdata.txt file for use as trust anchors for the p11-kit-0.24.1 trust module. Additionally, it will generate system certificate stores used by BLFS applications (if the recommended and optional applications are present on the system). Any local certificates stored in /etc/ssl/local will be imported to both the trust anchors and the generated certificate stores (overriding Mozilla’s trust). Additionally, any modified trust values will be copied from the trust anchors to /etc/ssl/local prior to any updates, preserving custom trust values that differ from Mozilla when using the trust utility from p11-kit to operate on the trust store.

To install the various certificate stores, first install the make-ca script into the correct location. As the root user:

make install &&
install -vdm755 /etc/ssl/local

As the root user, after installing p11-kit-0.24.1, download the certificate source and prepare for system use with the following command:

Note

If running the script a second time with the same version of certdata.txt, for instance, to update the stores when make-ca is upgraded, or to add additional stores as the requisite software is installed, replace the -g switch with the -r switch in the command line. If packaging, run make-ca –help to see all available command line options.

/usr/sbin/make-ca -g

You should periodically update the store with the above command, either manually, or via a systemd timer. A timer is installed at /usr/lib/systemd/system/update-pki.timer that, if enabled, will check for updates weekly. Execute the following commands, as the root user, to enable the systemd timer:

systemctl enable update-pki.timer

Configuring make-ca

For most users, no additional configuration is necessary, however, the default certdata.txt file provided by make-ca is obtained from the mozilla-release branch, and is modified to provide a Mercurial revision. This will be the correct version for most systems. There are several other variants of the file available for use that might be preferred for one reason or another, including the files shipped with Mozilla products in this book. RedHat and OpenSUSE, for instance, use the version included in nss-3.88.1. Additional upstream downloads are available at the links included in /etc/make-ca/make-ca.conf.dist. Simply copy the file to /etc/make-ca.conf and edit as appropriate.

About Trust Arguments

There are three trust types that are recognized by the make-ca script, SSL/TLS, S/Mime, and code signing. For OpenSSL, these are serverAuth, emailProtection, and codeSigning respectively. If one of the three trust arguments is omitted, the certificate is neither trusted, nor rejected for that role. Clients that use OpenSSL or NSS encountering this certificate will present a warning to the user. Clients using GnuTLS without p11-kit support are not aware of trusted certificates. To include this CA into the ca-bundle.crt, email-ca-bundle.crt, or objsign-ca-bundle.crt files (the GnuTLS legacy bundles), it must have the appropriate trust arguments.

Adding Additional CA Certificates

The /etc/ssl/local directory is available to add additional CA certificates to the system trust store. This directory is also used to store certificates that were added to or modified in the system trust store by p11-kit-0.24.1 so that trust values are maintained across upgrades. Files in this directory must be in the OpenSSL trusted certificate format. Certificates imported using the trust utility from p11-kit-0.24.1 will utilize the x509 Extended Key Usage values to assign default trust values for the system anchors.

If you need to override trust values, or otherwise need to create an OpenSSL trusted certificate manually from a regular PEM encoded file, you need to add trust arguments to the openssl command, and create a new certificate. For example, using the CAcert roots, if you want to trust both for all three roles, the following commands will create appropriate OpenSSL trusted certificates (run as the root user after Wget-1.21.3 is installed):

wget http://www.cacert.org/certs/root.crt &&
wget http://www.cacert.org/certs/class3.crt &&
openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" \
        -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
        > /etc/ssl/local/CAcert_Class_1_root.pem &&
openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 root" \
        -addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
        > /etc/ssl/local/CAcert_Class_3_root.pem &&
/usr/sbin/make-ca -r

Overriding Mozilla Trust

Occasionally, there may be instances where you don’t agree with Mozilla’s inclusion of a particular certificate authority. If you’d like to override the default trust of a particular CA, simply create a copy of the existing certificate in /etc/ssl/local with different trust arguments. For example, if you’d like to distrust the “Makebelieve_CA_Root” file, run the following commands:

openssl x509 -in /etc/ssl/certs/Makebelieve_CA_Root.pem \
             -text \
             -fingerprint \
             -setalias "Disabled Makebelieve CA Root" \
             -addreject serverAuth \
             -addreject emailProtection \
             -addreject codeSigning \
       > /etc/ssl/local/Disabled_Makebelieve_CA_Root.pem &&
/usr/sbin/make-ca -r

Using make-ca with Python3

When Python3 was installed in LFS it included the pip3 module with vendored certificates from the Certifi module. That was necessary, but it means that whenever pip3 is used it can reference those certificates, primarily when creating a virtual environment or when installing a module with all its wheel dependencies in one go.

It is generally considered that the System Administrator should be in charge of which certificates are available. Now that make-ca-1.12 and p11-kit-0.24.1 have been installed and make-ca has been configured, it is possible to make pip3 use the system certificates.

The vendored certificates installed in LFS are a snapshot from when the pulled-in version of Certifi was created. If you regularly update the system certificates, the vendored version will become out of date.

To use the system certificates in Python3 you should set _PIP_STANDALONE_CERT to point to them, e.g for the bash shell:

export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt

Warning

If you have created virtual environments, for example when testing modules, and those include the Requests and Certifi modules in ~/.local/lib/python3.11/ then those local modules will be used instead of the system certificates unless you remove the local modules.

To use the system certificates in Python3 with the BLFS profiles add the following variable to your system or personal profiles:

mkdir -pv /etc/profile.d &&
cat > /etc/profile.d/pythoncerts.sh << "EOF"
# Begin /etc/profile.d/pythoncerts.sh

export _PIP_STANDALONE_CERT=/etc/pki/tls/certs/ca-bundle.crt

# End /etc/profile.d/pythoncerts.sh
EOF

Contents

Installed Programs: make-ca

Installed Directories: /etc/ssl/{certs,local} and /etc/pki/{nssdb,anchors,tls/{certs,java}}

Short Descriptions

make-ca is a shell script that adapts a current version of certdata.txt, and prepares it for use as the system trust store

4.3 CrackLib-2.9.8

Introduction to CrackLib

The CrackLib package contains a library used to enforce strong passwords by comparing user selected passwords to words in chosen word lists.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

There are additional word lists available for download, e.g., from https://wiki.skullsecurity.org/index.php/Passwords. CrackLib can utilize as many, or as few word lists you choose to install.

Important

Users tend to base their passwords on regular words of the spoken language, and crackers know that. CrackLib is intended to filter out such bad passwords at the source using a dictionary created from word lists. To accomplish this, the word list(s) for use with CrackLib must be an exhaustive list of words and word-based keystroke combinations likely to be chosen by users of the system as (guessable) passwords.

The default word list recommended above for downloading mostly satisfies this role in English-speaking countries. In other situations, it may be necessary to download (or even create) additional word lists.

Note that word lists suitable for spell-checking are not usable as CrackLib word lists in countries with non-Latin based alphabets, because of “word-based keystroke combinations” that make bad passwords.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/cracklib

Installation of CrackLib

Install CrackLib by running the following commands:

autoreconf -fiv &&

PYTHON=python3               \
./configure --prefix=/usr    \
            --disable-static \
            --with-default-dict=/usr/lib/cracklib/pw_dict &&
make

Now, as the root user:

make install

Issue the following commands as the root user to install the recommended word list and create the CrackLib dictionary. Other word lists (text based, one word per line) can also be used by simply installing them into /usr/share/dict and adding them to the create-cracklib-dict command.

install -v -m644 -D    ../cracklib-words-2.9.8.bz2 \
                         /usr/share/dict/cracklib-words.bz2    &&

bunzip2 -v               /usr/share/dict/cracklib-words.bz2    &&
ln -v -sf cracklib-words /usr/share/dict/words                 &&
echo $(hostname) >>      /usr/share/dict/cracklib-extra-words  &&
install -v -m755 -d      /usr/lib/cracklib                     &&

create-cracklib-dict     /usr/share/dict/cracklib-words \
                         /usr/share/dict/cracklib-extra-words

If desired, check the proper operation of the library as an unprivileged user by issuing the following command:

make test

Important

If you are installing CrackLib after your LFS system has been completed and you have the Shadow package installed, you must reinstall Shadow-4.13 if you wish to provide strong password support on your system. If you are now going to install the Linux-PAM-1.5.2 package, you may disregard this note as Shadow will be reinstalled after the Linux-PAM installation.

Command Explanations

sed -i ‘/skipping/d’ util/packer.c: Remove a meaningless warning.

autoreconf -fiv: The configure script shipped with the package is too old to get the right version string of Python 3.10 or later. This command regenerates it with a more recent version of autotools, which fixes the issue.

PYTHON=python3: This forces the installation of python bindings for Python 3, even if Python 2 is installed.

--with-default-dict=/lib/cracklib/pw_dict: This parameter forces the installation of the CrackLib dictionary to the /lib hierarchy.

--disable-static: This switch prevents installation of static versions of the libraries.

install -v -m644 -D …: This command creates the /usr/share/dict directory (if it doesn’t already exist) and installs the compressed word list there.

ln -v -s cracklib-words /usr/share/dict/words: The word list is linked to /usr/share/dict/words as historically, words is the primary word list in the /usr/share/dict directory. Omit this command if you already have a /usr/share/dict/words file installed on your system.

echo $(hostname) »…: The value of hostname is echoed to a file called cracklib-extra-words. This extra file is intended to be a site specific list which includes easy to guess passwords such as company or department names, user names, product names, computer names, domain names, etc.

create-cracklib-dict …: This command creates the CrackLib dictionary from the word lists. Modify the command to add any additional word lists you have installed.

Contents

Installed Programs: cracklib-check, cracklib-format, cracklib-packer, cracklib-unpacker and create-cracklib-dict

Installed Libraries: libcrack.so and the _cracklib.so (Python module)

Installed Directories: /lib/cracklib, /usr/share/dict and /usr/share/cracklib

Short Descriptions

cracklib-check is used to determine if a password is strong

cracklib-format is used to format text files (lowercases all words, removes control characters and sorts the lists)

cracklib-packer creates a database with words read from standard input

cracklib-unpacker displays on standard output the database specified

create-cracklib-dict is used to create the CrackLib dictionary from the given word list(s)

libcrack.so provides a fast dictionary lookup method for strong password enforcement.

4.4 cryptsetup-2.4.3

Introduction to cryptsetup

cryptsetup is used to set up transparent encryption of block devices using the kernel crypto API.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

cryptsetup Dependencies

Required

JSON-C-0.16, LVM2-2.03.18, and popt-1.19

Optional

libpwquality-1.4.5, argon2, libssh, and passwdqc

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/cryptsetup

Kernel Configuration

Encrypted block devices require kernel support. To use it, the appropriate kernel configuration parameters need to be set:

Device Drivers  --->
    [*] Multiple devices driver support (RAID and LVM) ---> [CONFIG_MD]
        <*/M> Device mapper support                         [CONFIG_BLK_DEV_DM]
        <*/M> Crypt target support                          [CONFIG_DM_CRYPT]

Cryptographic API  --->
    <*/M> XTS support                                       [CONFIG_CRYPTO_XTS]
    <*/M> SHA224 and SHA256 digest algorithm                [CONFIG_CRYPTO_SHA256]
    <*/M> AES cipher algorithms                             [CONFIG_CRYPTO_AES]
    <*/M> User-space interface for symmetric key cipher algorithms
                                                            [CONFIG_CRYPTO_USER_API_SKCIPHER]
    For tests:
    <*/M> Twofish cipher algorithm                          [CONFIG_CRYPTO_TWOFISH]

Installation of cryptsetup

Install cryptsetup by running the following commands:

./configure --prefix=/usr --disable-ssh-token &&
make

To test the result, issue as the root user: make check. Some tests will fail if appropriate kernel configuration options are not set. Some additional options that may be needed for tests are: CONFIG_SCSI_LOWLEVEL, CONFIG_SCSI_DEBUG, CONFIG_BLK_DEV_DM_BUILTIN, CONFIG_CRYPTO_USER, CONFIG_CRYPTO_CRYPTD, CONFIG_CRYPTO_LRW, CONFIG_CRYPTO_XTS, CONFIG_CRYPTO_ESSIV, CONFIG_CRYPTO_CRCT10DIF, CONFIG_CRYPTO_AES_TI, CONFIG_CRYPTO_AES_NI_INTEL, CONFIG_CRYPTO_BLOWFISH, CONFIG_CRYPTO_CAST5, CONFIG_CRYPTO_SERPENT, CONFIG_CRYPTO_SERPENT_SSE2_X86_64, CONFIG_CRYPTO_SERPENT_AVX_X86_64, CONFIG_CRYPTO_SERPENT_AVX2_X86_64, and CONFIG_CRYPTO_TWOFISH_X86_64.

Now, as the root user:

make install

Command Explanations

--disable-ssh-token: This option is required if the optional libssh dependency is not installed.

Configuring cryptsetup

Because of the number of possible configurations, setup of encrypted volumes is beyond the scope of the BLFS book. Please see the configuration guide in the cryptsetup FAQ.

Contents

Installed Programs: cryptsetup, cryptsetup-reencrypt, integritysetup, and veritysetup

Installed Libraries: libcryptsetup.so

Installed Directories: None

Short Descriptions

cryptsetup is used to setup dm-crypt managed device-mapper mappings

cryptsetup-reencrypt is a tool for offline LUKS device re-encryption

integritysetup is a tool to manage dm-integrity (block level integrity) volumes

veritysetup is used to configure dm-verity managed device-mapper mappings. Device-mapper verity target provides read-only transparent integrity checking of block devices using kernel crypto API

4.5 Cyrus SASL-2.1.28

Introduction to Cyrus SASL

The Cyrus SASL package contains a Simple Authentication and Security Layer implementation, a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Cyrus SASL Dependencies

Berkeley DB-5.3.28

Optional

Linux-PAM-1.5.2, MIT Kerberos V5-1.20.1, MariaDB-10.6.12 or MySQL, OpenLDAP-2.6.4, PostgreSQL-15.2, sphinx-6.1.3, SQLite-3.40.1, krb4, Dmalloc, and Pod::POM::View::Restructured

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/cyrus-sasl

Installation of Cyrus SASL

Note

This package does not support parallel build.

Install Cyrus SASL by running the following commands:

./configure --prefix=/usr        \
            --sysconfdir=/etc    \
            --enable-auth-sasldb \
            --with-dbpath=/var/lib/sasl/sasldb2 \
            --with-sphinx-build=no              \
            --with-saslauthd=/var/run/saslauthd &&
make -j1

This package does not come with a test suite. If you are planning on using the GSSAPI authentication mechanism, test it after installing the package using the sample server and client programs which were built in the preceding step. Instructions for performing the tests can be found at https://www.linuxfromscratch.org/hints/downloads/files/cyrus-sasl.txt.

Now, as the root user:

make install &&
install -v -dm755                          /usr/share/doc/cyrus-sasl-2.1.28/html &&
install -v -m644  saslauthd/LDAP_SASLAUTHD /usr/share/doc/cyrus-sasl-2.1.28      &&
install -v -m644  doc/legacy/*.html        /usr/share/doc/cyrus-sasl-2.1.28/html &&
install -v -dm700 /var/lib/sasl

Command Explanations

--with-dbpath=/var/lib/sasl/sasldb2: This switch forces the sasldb database to be created in /var/lib/sasl instead of /etc.

--with-saslauthd=/var/run/saslauthd: This switch forces saslauthd to use the FHS compliant directory /var/run/saslauthd for variable run-time data.

--enable-auth-sasldb: This switch enables SASLDB authentication backend.

--with-dblib=gdbm: This switch forces GDBM to be used instead of Berkeley DB.

--with-ldap: This switch enables the OpenLDAP support.

--enable-ldapdb: This switch enables the LDAPDB authentication backend.

--enable-login: This option enables unsupported LOGIN authentication.

--enable-ntlm: This option enables unsupported NTLM authentication.

install -v -m644 …: These commands install documentation which is not installed by the make install command.

install -v -m700 -d /var/lib/sasl: This directory must exist when starting saslauthd or using the sasldb plugin. If you’re not going to be running the daemon or using the plugins, you may omit the creation of this directory.

Configuring Cyrus SASL

Config Files

/etc/saslauthd.conf (for saslauthd LDAP configuration) and /etc/sasl2/Appname.conf (where “Appname” is the application defined name of the application)

Configuration Information

See https://www.cyrusimap.org/sasl/sasl/sysadmin.html for information on what to include in the application configuration files.

See file:///usr/share/doc/cyrus-sasl-2.1.28/LDAP_SASLAUTHD for configuring saslauthd with OpenLDAP.

See https://www.cyrusimap.org/sasl/sasl/gssapi.html#gssapi for configuring saslauthd with Kerberos.

Systemd Unit

If you need to run the saslauthd daemon at system startup, install the saslauthd.service unit included in the blfs-systemd-units-20220720 package using the following command:

make install-saslauthd

Note

You’ll need to modify /etc/default/saslauthd and modify the MECHANISM parameter with your desired authentication mechanism. The default authentication mechanism is “shadow”.

Contents

Installed Programs: pluginviewer, saslauthd, sasldblistusers2, saslpasswd2 and testsaslauthd

Installed Library: libsasl2.so

Installed Directories: /usr/include/sasl, /usr/lib/sasl2, /usr/share/doc/cyrus-sasl-2.1.28 and /var/lib/sasl

Short Descriptions

pluginviewer is used to list loadable SASL plugins and their properties

saslauthd is the SASL authentication server

sasldblistusers2 is used to list the users in the SASL password database sasldb2

saslpasswd2 is used to set and delete a user’s SASL password and mechanism specific secrets in the SASL password database sasldb2

testsaslauthd is a test utility for the SASL authentication server

libsasl2.so is a general purpose authentication library for server and client applications.

4.6 GnuPG-2.4.0

Introduction to GnuPG

The GnuPG package is GNU’s tool for secure communication and data storage. It can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440 and the S/MIME standard as described by several RFCs. GnuPG 2 is the stable version of GnuPG integrating support for OpenPGP and S/MIME.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

GnuPG 2 Dependencies

Required

libassuan-2.5.5, libgcrypt-1.10.1, libksba-1.6.3, and npth-1.6

GnuTLS-3.8.0 (required to communicate with keyservers using https or hkps protocol) and pinentry-1.2.1 (Run-time requirement for most of the package’s functionality)

Optional

cURL-7.88.1, Fuse-3.13.1, ImageMagick-7.1.0-61 (for the convert utility, used for generating the documentation), libusb-1.0.26, an MTA, OpenLDAP-2.6.4, SQLite-3.40.1, texlive-20220321 (or install-tl-unx), fig2dev (for generating documentation), and GNU adns

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/gnupg2

Installation of GnuPG

Install GnuPG by running the following commands:

mkdir build &&
cd    build &&

../configure --prefix=/usr           \
             --localstatedir=/var    \
             --sysconfdir=/etc       \
             --docdir=/usr/share/doc/gnupg-2.4.0 &&
make &&

makeinfo --html --no-split -I doc -o doc/gnupg_nochunks.html ../doc/gnupg.texi &&
makeinfo --plaintext       -I doc -o doc/gnupg.txt           ../doc/gnupg.texi &&
make -C doc html

If you have texlive-20220321 installed and you wish to create documentation in alternate formats, issue the following commands (fig2dev is needed for the ps format):

make -C doc pdf ps

To test the results, issue: make check.

Now, as the root user:

make install &&

install -v -m755 -d /usr/share/doc/gnupg-2.4.0/html            &&
install -v -m644    doc/gnupg_nochunks.html \
                    /usr/share/doc/gnupg-2.4.0/html/gnupg.html &&
install -v -m644    ../doc/*.texi doc/gnupg.txt \
                    /usr/share/doc/gnupg-2.4.0 &&
install -v -m644    doc/gnupg.html/* \
                    /usr/share/doc/gnupg-2.4.0/html

If you created alternate formats of the documentation, install them using the following command as the root user:

install -v -m644 doc/gnupg.{pdf,dvi,ps} \
                 /usr/share/doc/gnupg-2.4.0

Command Explanations

mkdir build && cd build: the Gnupg2 developers recommend to build the package in a dedicated directory.

--docdir=/usr/share/doc/gnupg-2.4.0: This switch changes the default docdir to /usr/share/doc/gnupg-2.4.0.

--enable-all-tests: This switch allows more tests to be run with make check.

--enable-g13: This switch enables building the g13 program.

Contents

Installed Programs: addgnupghome, applygnupgdefaults, dirmngr, dirmngr-client, g13 (optional), gpg-agent, gpg-card, gpg-connect-agent, gpg, gpgconf, gpgparsemail, gpgscm, gpgsm, gpgsplit, gpgtar, gpgv, gpg-wks-client, gpg-wks-server, kbxutil, and watchgnupg

Installed Libraries: None

Installed Directories: /usr/share/doc/gnupg-2.4.0 and /usr/share/gnupg

Short Descriptions

addgnupghome is used to create and populate a user’s ~/.gnupg directories

applygnupgdefaults is a wrapper script used to run gpgconf with the --apply-defaults parameter on all user’s GnuPG home directories

dirmngr is a tool that takes care of accessing the OpenPGP keyservers

dirmngr-client is a tool to contact a running dirmngr and test whether a certificate has been revoked

g13 is a tool to create, mount or unmount an encrypted file system container (optional)

gpg-agent is a daemon used to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities

gpg-card is a tool to manage smart cards and tokens

gpg-connect-agent is a utility used to communicate with a running gpg-agent

gpg is the OpenPGP part of the GNU Privacy Guard (GnuPG). It is a tool used to provide digital encryption and signing services using the OpenPGP standard

gpgconf is a utility used to automatically and reasonably safely query and modify configuration files in the ~/.gnupg home directory. It is designed not to be invoked manually by the user, but automatically by graphical user interfaces

gpgparsemail is a utility currently only useful for debugging. Run it with --help for usage information

gpgscm executes the given scheme program or spawns an interactive shell

gpgsm is a tool similar to gpg used to provide digital encryption and signing services on X.509 certificates and the CMS protocol. It is mainly used as a backend for S/MIME mail processing

gpgsplit splits an OpenPGP message into packets

gpgtar is a tool to encrypt or sign files into an archive

gpgv is a verify only version of gpg

gpg-wks-client is a client for the Web Key Service protocol

gpg-wks-server provides a server for the Web Key Service protocol

kbxutil is used to list, export and import Keybox data

watchgnupg is used to listen to a Unix Domain socket created by any of the GnuPG tools.

4.7 GnuTLS-3.8.0

Introduction to GnuTLS

The GnuTLS package contains libraries and userspace tools which provide a secure layer over a reliable transport layer. Currently the GnuTLS library implements the proposed standards by the IETF’s TLS working group. Quoting from the TLS 1.3 protocol specification :

“ TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. ”

GnuTLS provides support for TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, and (optionally) SSL 3.0 protocols. It also supports TLS extensions, including server name and max record size. Additionally, the library supports authentication using the SRP protocol, X.509 certificates, and OpenPGP keys, along with support for the TLS Pre-Shared-Keys (PSK) extension, the Inner Application (TLS/IA) extension, and X.509 and OpenPGP certificate handling.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

GnuTLS Dependencies

Required

Nettle-3.8.1

make-ca-1.12, libunistring-1.1, libtasn1-4.19.0, and p11-kit-0.24.1

Optional

Brotli-1.0.9, Doxygen-1.9.6, GTK-Doc-1.33.2, libidn-1.41 or libidn2-2.3.4, libseccomp-2.5.4, Net-tools-2.10 (used during the test suite), texlive-20220321 or install-tl-unx, Unbound-1.17.1 (to build the DANE library), Valgrind-3.20.0 (used during the test suite), autogen, cmocka and datefudge (used during the test suite if the DANE library is built), and Trousers (Trusted Platform Module support)

Note

Note that if you do not install libtasn1-4.19.0, a version shipped in the GnuTLS tarball will be used instead.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/gnutls

Installation of GnuTLS

Install GnuTLS by running the following commands:

./configure --prefix=/usr \
            --docdir=/usr/share/doc/gnutls-3.8.0 \
            --with-default-trust-store-pkcs11="pkcs11:" &&
make

To test the results, issue: make check.

Now, as the root user:

make install

Command Explanations

--with-default-trust-store-pkcs11="pkcs11:": This switch tells gnutls to use the PKCS #11 trust store as the default trust. Omit this switch if p11-kit-0.24.1 is not installed.

--with-default-trust-store-file=/etc/pki/tls/certs/ca-bundle.crt: This switch tells configure where to find the legacy CA certificate bundle and to use it instead of PKCS #11 module by default. Use this if p11-kit-0.24.1 is not installed.

--enable-gtk-doc: Use this parameter if GTK-Doc is installed and you wish to rebuild and install the API documentation.

--enable-openssl-compatibility: Use this switch if you wish to build the OpenSSL compatibility library.

--without-p11-kit: use this switch if you have not installed p11-kit.

--with-included-unistring: uses the bundled version of libunistring, instead of the system one. Use this switch if you have not installed libunistring-1.1.

Contents

Installed Programs: certtool, danetool, gnutls-cli, gnutls-cli-debug, gnutls-serv, ocsptool, p11tool, psktool, and srptool

Installed Libraries: libgnutls.so, libgnutls-dane.so, libgnutlsxx.so, libgnutls-openssl.so (optional), and /usr/lib/guile/3.0/extensions/guile-gnutls-v-2.so

Installed Directories: /usr/include/gnutls, /usr/lib/guile/3.0/site-ccache/gnutls, /usr/share/guile/site/3.0/gnutls, and /usr/share/doc/gnutls-3.8.0

Short Descriptions

certtool is used to generate X.509 certificates, certificate requests, and private keys

danetool is a tool used to generate and check DNS resource records for the DANE protocol

gnutls-cli is a simple client program to set up a TLS connection to some other computer

gnutls-cli-debug is a simple client program to set up a TLS connection to some other computer and produces very verbose progress results

gnutls-serv is a simple server program that listens to incoming TLS connections

ocsptool is a program that can parse and print information about OCSP requests/responses, generate requests and verify responses

p11tool is a program that allows handling data from PKCS #11 smart cards and security modules

psktool is a simple program that generates random keys for use with TLS-PSK

srptool is a simple program that emulates the programs in the Stanford SRP (Secure Remote Password) libraries using GnuTLS

libgnutls.so contains the core API functions and X.509 certificate API functions.

4.8 GPGME-1.18.0

Introduction to GPGME

The GPGME package is a C library that allows cryptography support to be added to a program. It is designed to make access to public key crypto engines like GnuPG or GpgSM easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

GPGME Dependencies

Required

libassuan-2.5.5

Optional

Doxygen-1.9.6 and Graphviz-7.1.0 (for API documentation), GnuPG-2.4.0 (required if Qt or SWIG are installed; used during the test suite), Clisp-2.49, Qt-5.15.8, and/or SWIG-4.1.1 (for language bindings)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/gpgme

Installation of GPGME

First, fix an issue building with Python 3.11 installed:

sed -e 's/3\.9/3.11/'                    \
    -e 's/:3/:4/'                        \
    -i configure

Apply a patch to fix build failure with SWIG and libgpg-error-1.46 or later:

patch -Np1 -i ../gpgme-1.18.0-gpg_error_1_46-1.patch

Install GPGME by running the following commands:

./configure --prefix=/usr --disable-gpg-test &&
make

To test the results, you should have GnuPG-2.4.0 installed and remove the –disable-gpg-test above. Issue: make -k check.

Now, as the root user:

make install

Command Explanations

--disable-gpg-test: if this parameter is not passed to configure, the test programs are built during make stage, which requires GnuPG-2.4.0. This parameter is not needed if GnuPG-2.4.0 is installed.

Contents

Installed Program: gpgme-json, and gpgme-tool

Installed Libraries: libgpgme, libgpgmepp.so, and libqgpgme.so

Installed Directory: /usr/include/{gpgme++,qgpgme,QGpgME}, /usr/lib/cmake/{Gpgmepp,QGpgme}. /usr/lib/python{2.7,3.9}/site-packages/gpg, and /usr/share/common-lisp/source/gpgme

Short Descriptions

gpgme-json outputs GPGME commands in JSON format

gpgme-tool is an assuan server exposing GPGME operations, such as printing fingerprints and keyids with keyservers

libgpgme.so contains the GPGME API functions

libgpgmepp.so contains the C++ GPGME API functions

libqgpgme.so contains API functions for handling GPG operations in Qt applications.

4.9 iptables-1.8.9

Introduction to iptables

iptables is a userspace command line program used to configure the Linux 2.4 and later kernel packet filtering ruleset.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

iptables Dependencies

Optional

libpcap-1.10.3 (required for nfsypproxy support), bpf-utils (required for Berkeley Packet Filter support), libnfnetlink (required for connlabel support), libnetfilter_conntrack (required for connlabel support), and nftables

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/iptables

Kernel Configuration

A firewall in Linux is accomplished through the netfilter interface. To use iptables to configure netfilter, the following kernel configuration parameters are required:

[*] Networking support  --->                                          [CONFIG_NET]
    Networking Options  --->
        [*] Network packet filtering framework (Netfilter) --->       [CONFIG_NETFILTER]
            [*] Advanced netfilter configuration                        [CONFIG_NETFILTER_ADVANCED]
            Core Netfilter Configuration --->
                <*/M> Netfilter connection tracking support               [CONFIG_NF_CONNTRACK]
                <*/M> Netfilter Xtables support (required for ip_tables)  [CONFIG_NETFILTER_XTABLES]
                <*/M> LOG target support                                  [CONFIG_NETFILTER_XT_TARGET_LOG]
            IP: Netfilter Configuration --->
                <*/M> IP tables support (required for filtering/masq/NAT) [CONFIG_IP_NF_IPTABLES]

Include any connection tracking protocols that will be used, as well as any protocols that you wish to use for match support under the “Core Netfilter Configuration” section. The above options are enough for running Creating a Personal Firewall With iptables below.

Installation of iptables

Note

The installation below does not include building some specialized extension libraries which require the raw headers in the Linux source code. If you wish to build the additional extensions (if you aren’t sure, then you probably don’t), you can look at the INSTALL file to see an example of how to change the KERNEL_DIR= parameter to point at the Linux source code. Note that if you upgrade the kernel version, you may also need to recompile iptables and that the BLFS team has not tested using the raw kernel headers.

Install iptables by running the following commands:

./configure --prefix=/usr      \
            --disable-nftables \
            --enable-libipq    &&
make

This package does not come with a test suite.

Now, as the root user:

make install

Command Explanations

--disable-nftables: This switch disables building nftables compatibility.

--enable-libipq: This switch enables building of libipq.so which can be used by some packages outside of BLFS.

--enable-nfsynproxy: This switch enables installation of nfsynproxy SYNPROXY configuration tool.

Configuring iptables

Note

In the following example configurations, LAN1 is used for the internal LAN interface, and WAN1 is used for the external interface connected to the Internet. You will need to replace these values with appropriate interface names for your system.

Personal Firewall

A Personal Firewall is designed to let you access all the services offered on the Internet while keeping your computer secure and your data private.

Below is a slightly modified version of Rusty Russell’s recommendation from the Linux 2.4 Packet Filtering HOWTO. It is still applicable to the Linux 5.x kernels.

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

# Insert connection-tracking modules
# (not needed if built into the kernel)
modprobe nf_conntrack
modprobe xt_LOG

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects

# Do not send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface, where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians

# be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# disable Explicit Congestion Notification
# too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local-only connections
iptables -A INPUT  -i lo -j ACCEPT

# Free output on any interface to any ip for any service
# (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT

# Permit answers on already established connections
# and permit new connections related to established ones
# (e.g. port mode ftp)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Log everything else.
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

This script is quite simple, it drops all traffic coming into your computer that wasn’t initiated from your computer, but as long as you are simply surfing the Internet you are unlikely to exceed its limits.

If you frequently encounter certain delays at accessing FTP servers, take a look at BusyBox with iptables example number 4.

Even if you have daemons or services running on your system, these will be inaccessible everywhere but from your computer itself. If you want to allow access to services on your machine, such as ssh or ping, take a look at Creating a BusyBox With iptables.

Masquerading Router

A Network Firewall has two interfaces, one connected to an intranet, in this example LAN1, and one connected to the Internet, here WAN1. To provide the maximum security for the firewall itself, make sure that there are no unnecessary servers running on it such as X11. As a general principle, the firewall itself should not access any untrusted service (think of a remote server giving answers that makes a daemon on your system crash, or even worse, that implements a worm via a buffer-overflow).

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

echo
echo "You're using the example configuration for a setup of a firewall"
echo "from Beyond Linux From Scratch."
echo "This example is far from being complete, it is only meant"
echo "to be a reference."
echo "Firewall security is a complex issue, that exceeds the scope"
echo "of the configuration rules below."

echo "You can find additional information"
echo "about firewalls in Chapter 4 of the BLFS book."
echo "https://www.linuxfromscratch.org/blfs"
echo

# Insert iptables modules (not needed if built into the kernel).

modprobe nf_conntrack
modprobe nf_conntrack_ftp
modprobe xt_conntrack
modprobe xt_LOG
modprobe xt_state

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# Don't send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# Be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# Disable Explicit Congestion Notification
# Too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local connections
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow forwarding if the initiated on the intranet
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i WAN1 -m conntrack --ctstate NEW       -j ACCEPT

# Do masquerading
# (not needed if intranet is not using private ip-addresses)
iptables -t nat -A POSTROUTING -o WAN1 -j MASQUERADE

# Log everything for debugging
# (last of all rules, but before policy rules)
iptables -A INPUT   -j LOG --log-prefix "FIREWALL:INPUT "
iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD "
iptables -A OUTPUT  -j LOG --log-prefix "FIREWALL:OUTPUT "

# Enable IP Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# The following sections allow inbound packets for specific examples
# Uncomment the example lines and adjust as necessary

# Allow ping on the external interface
#iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
#iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT

# Reject ident packets with TCP reset to avoid delays with FTP or IRC
#iptables -A INPUT  -p tcp --dport 113 -j REJECT --reject-with tcp-reset

# Allow HTTP and HTTPS to 192.168.0.2
#iptables -A PREROUTING -t nat -i WAN1 -p tcp --dport 80 -j DNAT --to 192.168.0.2
#iptables -A PREROUTING -t nat -i WAN1 -p tcp --dport 443 -j DNAT --to 192.168.0.2
#iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 80 -j ACCEPT
#iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 443 -j ACCEPT

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

With this script your intranet should be reasonably secure against external attacks. No one should be able to setup a new connection to any internal service and, if it’s masqueraded, makes your intranet invisible to the Internet. Furthermore, your firewall should be relatively safe because there are no services running that a cracker could attack.

BusyBox

This scenario isn’t too different from the Creating a Masquerading Router With iptables, but additionally offers some services to your intranet. Examples of this can be when you want to administer your firewall from another host on your intranet or use it as a proxy or a name server.

Note

Outlining specifically how to protect a server that offers services on the Internet goes far beyond the scope of this document. See the references in the section called “Extra Information” for more information.

Be cautious. Every service you have enabled makes your setup more complex and your firewall less secure. You are exposed to the risks of misconfigured services or running a service with an exploitable bug. A firewall should generally not run any extra services. See the introduction to the Creating a Masquerading Router With iptables for some more details.

If you want to add services such as internal Samba or name servers that do not need to access the Internet themselves, the additional statements are quite simple and should still be acceptable from a security standpoint. Just add the following lines into the script before the logging rules.

iptables -A INPUT  -i ! WAN1  -j ACCEPT
iptables -A OUTPUT -o ! WAN1  -j ACCEPT

If daemons, such as squid, have to access the Internet themselves, you could open OUTPUT generally and restrict INPUT.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT

However, it is generally not advisable to leave OUTPUT unrestricted. You lose any control over trojans who would like to “call home”, and a bit of redundancy in case you’ve (mis-)configured a service so that it broadcasts its existence to the world.

To accomplish this, you should restrict INPUT and OUTPUT on all ports except those that it’s absolutely necessary to have open. Which ports you have to open depends on your needs: mostly you will find them by looking for failed accesses in your log files.

Have a Look at the Following Examples:

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT  -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED \
  -j ACCEPT

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT

iptables -A INPUT  -p tcp --dport 113 -j REJECT --reject-with tcp-reset

iptables -I INPUT 0 -p tcp -m conntrack --ctstate INVALID \
  -j LOG --log-prefix "FIREWALL:INVALID "
iptables -I INPUT 1 -p tcp -m conntrack --ctstate INVALID -j DROP

iptables -A INPUT -i WAN1 -s 10.0.0.0/8     -j DROP
iptables -A INPUT -i WAN1 -s 172.16.0.0/12  -j DROP
iptables -A INPUT -i WAN1 -s 192.168.0.0/16 -j DROP

There are other addresses that you may also want to drop: 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/3 (multicast and experimental), 169.254.0.0/16 (Link Local Networks), and 192.0.2.0/24 (IANA defined test network).

iptables -A INPUT  -i WAN1 -p udp -s 0.0.0.0 --sport 67 \
   -d 255.255.255.255 --dport 68 -j ACCEPT

iptables -A INPUT -j REJECT

These are only examples to show you some of the capabilities of the firewall code in Linux. Have a look at the man page of iptables. There you will find much more information. The port numbers needed for this can be found in /etc/services, in case you didn’t find them by trial and error in your log file.

Systemd Unit

To set up the iptables firewall at boot, install the iptables.service unit included in the blfs-systemd-units-20220720 package.

make install-iptables

Contents

Installed Programs: ip6tables, ip6tables-apply, ip6tables-legacy, ip6tables-legacy-restore, ip6tables-legacy-save, ip6tables-restore, ip6tables-save, iptables, iptables-apply, iptables-legacy, iptables-legacy-restore, iptables-legacy-apply, iptables-restore, iptables-save, iptables-xml, nfsynproxy (optional), and xtables-multi

Installed Libraries: libip4tc.so, libip6tc.so, libipq.so, libiptc.so, and libxtables.so

Installed Directories: /lib/xtables and /usr/include/libiptc

Short Descriptions

iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel

iptables-apply is a safer way to update iptables remotely

iptables-legacy is used to interact with iptables using the legacy command set

iptables-legacy-restore is used to restore a set of legacy iptables rules

iptables-legacy-save is used to save a set of legacy iptables rules

iptables-restore is used to restore IP Tables from data specified on STDIN. Use I/O redirection provided by your shell to read from a file

iptables-save is used to dump the contents of an IP Table in easily parseable format to STDOUT. Use I/O-redirection provided by your shell to write to a file

iptables-xml is used to convert the output of iptables-save to an XML format. Using the iptables.xslt stylesheet converts the XML back to the format of iptables-restore

ip6tables* are a set of commands for IPV6 that parallel the iptables commands above

nfsynproxy (optional) configuration tool. SYNPROXY target makes handling of large SYN floods possible without the large performance penalties imposed by the connection tracking in such cases

xtables-multi is a binary that behaves according to the name it is called by.

4.10 Setting Up a Network Firewall

Introduction to Firewall Creation

The purpose of a firewall is to protect a computer or a network against malicious access. In a perfect world every daemon or service, on every machine, is perfectly configured and immune to security flaws, and all users are trusted implicitly to use the equipment as intended. However, this is rarely, if ever, the case. Daemons may be misconfigured, or updates may not have been applied for known exploits against essential services. Additionally, you may wish to choose which services are accessible by certain machines or users, or you may wish to limit which machines or applications are allowed external access. Alternatively, you simply may not trust some of your applications or users. For these reasons, a carefully designed firewall should be an essential part of system security.

While a firewall can greatly limit the scope of the above issues, do not assume that having a firewall makes careful configuration redundant, or that any negligent misconfiguration is harmless. A firewall does not prevent the exploitation of any service you offer outside of it. Despite having a firewall, you need to keep applications and daemons properly configured and up to date.

Meaning of the Word “Firewall”

The word firewall can have several different meanings.

Personal Firewall

This is a hardware device or software program, intended to secure a home or desktop computer connected to the Internet. This type of firewall is highly relevant for users who do not know how their computers might be accessed via the Internet or how to disable that access, especially if they are always online and connected via broadband links.

An example configuration for a personal firewall is provided at Creating a Personal Firewall With iptables.

Masquerading Router

This is a system placed between the Internet and an intranet. To minimize the risk of compromising the firewall itself, it should generally have only one role—that of protecting the intranet. Although not completely risk-free, the tasks of doing the routing and IP masquerading (rewriting IP headers of the packets it routes from clients with private IP addresses onto the Internet so that they seem to come from the firewall itself) are commonly considered relatively secure.

An example configuration for a masquerading firewall is provided at Creating a Masquerading Router With iptables.

BusyBox

This is often an old computer you may have retired and nearly forgotten, performing masquerading or routing functions, but offering non-firewall services such as a web-cache or mail. This may be used for home networks, but is not to be considered as secure as a firewall only machine because the combination of server and router/firewall on one machine raises the complexity of the setup.

An example configuration for a BusyBox is provided at Creating a BusyBox With iptables.

Firewall with a Demilitarized Zone

This type of firewall performs masquerading or routing, but grants public access to some branch of your network that is physically separated from your regular intranet and is essentially a separate network with direct Internet access. The servers on this network are those which must be easily accessible from both the Internet and intranet. The firewall protects both networks. This type of firewall has a minimum of three network interfaces.

Packetfilter

This type of firewall does routing or masquerading but does not maintain a state table of ongoing communication streams. It is fast but quite limited in its ability to block undesired packets without blocking desired packets.

Conclusion

Caution

The example configurations provided for iptables-1.8.9 are not intended to be a complete guide to securing systems. Firewalling is a complex issue that requires careful configuration. The configurations provided by BLFS are intended only to give examples of how a firewall works. They are not intended to fit any particular configuration and may not provide complete protection from an attack.

BLFS provides an utility to manage the kernel Netfilter interface, iptables-1.8.9. It has been around since early 2.4 kernels, and has been the standard since. This is likely the set of tools that will be most familiar to existing admins. Other tools have been developed more recently, see the list of further readings below for more details. Here you will find a list of URLs that contain comprehensive information about building firewalls and further securing your system.

Extra Information

Further Reading on Firewalls

www.netfilter.org - Homepage of the netfilter/iptables/nftables projects
Netfilter related FAQ
Netfilter related HOWTO’s
nftables HOWTO
tldp.org/LDP/nag2/x-087-2-firewall.html
tldp.org/HOWTO/Security-HOWTO.html
tldp.org/HOWTO/Firewall-HOWTO.html
linuxsecurity.com/howtos
www.e-infomax.com/ipmasq
www.circlemud.org/jelson/writings/security/index.htm
insecure.org/reading.html

4.11 libcap-2.67 with PAM

Introduction to libcap with PAM

The libcap package was installed in LFS, but if Linux-PAM support is desired, the PAM module must be built (after installation of Linux-PAM).

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

libcap Dependencies

Required

Linux-PAM-1.5.2

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/libcap

Installation of libcap

Note

If you are upgrading libcap from a previous version, use the instructions in LFS libcap page to upgrade libcap. If Linux-PAM-1.5.2 has been built, the PAM module will automatically be built too.

Install libcap by running the following commands:

make -C pam_cap

This package does not come with a test suite.

Now, as the root user:

install -v -m755 pam_cap/pam_cap.so /usr/lib/security &&
install -v -m644 pam_cap/capability.conf /etc/security

Configuring Libcap

In order to allow Linux-PAM to grant privileges based on POSIX capabilities, you need to add the libcap module to the beginning of the /etc/pam.d/system-auth file. Make the required edits with the following commands:

mv -v /etc/pam.d/system-auth{,.bak} &&
cat > /etc/pam.d/system-auth << "EOF" &&
# Begin /etc/pam.d/system-auth

auth      optional    pam_cap.so
EOF
tail -n +3 /etc/pam.d/system-auth.bak >> /etc/pam.d/system-auth

Additionally, you’ll need to modify the /etc/security/capability.conf file to grant necessary privileges to users, and utilize the setcap utility to set capabilities on specific utilities as needed. See man 8 setcap and man 3 cap_from_text for additional information.

Contents

Installed Programs: None

Installed Library: pam_cap.so

Installed Directories: None

4.12 Linux-PAM-1.5.2

Introduction to Linux PAM

The Linux PAM package contains Pluggable Authentication Modules used by the local system administrator to control how application programs authenticate users.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

Optional Documentation

Linux PAM Dependencies

Optional

Berkeley DB-5.3.28, libnsl-2.0.0, libtirpc-1.3.3, libaudit, and Prelude

Optional (To Rebuild the Documentation)

docbook-xml-4.5, docbook-xsl-nons-1.79.2, fop-2.8, libxslt-1.1.37 and either Lynx-2.8.9rel.1 or W3m

Note

Shadow-4.13 and Systemd-252 must be reinstalled and reconfigured after installing and configuring Linux PAM.

With Linux-PAM-1.4.0 and higher, the pam_cracklib module is not installed by default. Use libpwquality-1.4.5 to enforce strong passwords.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/linux-pam

Installation of Linux PAM

If you downloaded the documentation, unpack the tarball by issuing the following command.

tar -xf ../Linux-PAM-1.5.2-docs.tar.xz --strip-components=1

If you want to regenerate the documentation yourself, fix the configure script so it will detect lynx:

sed -e 's/dummy elinks/dummy lynx/'                                    \
    -e 's/-no-numbering -no-references/-force-html -nonumbers -stdin/' \
    -i configure

Compile and link Linux PAM by running the following commands:

./configure --prefix=/usr                        \
            --sbindir=/usr/sbin                  \
            --sysconfdir=/etc                    \
            --libdir=/usr/lib                    \
            --enable-securedir=/usr/lib/security \
            --docdir=/usr/share/doc/Linux-PAM-1.5.2 &&
make

To test the results, a suitable /etc/pam.d/other configuration file must exist.

Reinstallation or Upgrade of Linux PAM

If you have a system with Linux PAM installed and working, be careful when modifying the files in /etc/pam.d, since your system may become totally unusable. If you want to run the tests, you do not need to create another /etc/pam.d/other file. The existing file can be used for the tests.

You should also be aware that make install overwrites the configuration files in /etc/security as well as /etc/environment. If you have modified those files, be sure to back them up.

For a first-time installation, create a configuration file by issuing the following commands as the root user:

install -v -m755 -d /etc/pam.d &&

cat > /etc/pam.d/other << "EOF"
auth     required       pam_deny.so
account  required       pam_deny.so
password required       pam_deny.so
session  required       pam_deny.so
EOF

Now run the tests by issuing make check. Be sure the tests produced no errors before continuing the installation. Note that the tests are very long. Redirect the output to a log file, so you can inspect it thoroughly.

For a first-time installation, remove the configuration file created earlier by issuing the following command as the root user:

rm -fv /etc/pam.d/other

Now, as the root user:

make install &&
chmod -v 4755 /usr/sbin/unix_chkpwd

Command Explanations

--enable-securedir=/usr/lib/security: This switch sets the installation location for the PAM modules.

--disable-regenerate-docu : If the needed dependencies (docbook-xml-4.5, docbook-xsl-nons-1.79.2, libxslt-1.1.37, and Lynx-2.8.9rel.1 or W3m) are installed, the manual pages, and the html and text documentation files, are generated and installed. Furthermore, if fop-2.8 is installed, the PDF documentation is generated and installed. Use this switch if you do not want to rebuild the documentation.

chmod -v 4755 /usr/sbin/unix_chkpwd: The setuid bit for the unix_chkpwd helper program must be turned on, so that non-root processes can access the shadow file.

Configuring Linux-PAM

Configuration Files

/etc/security/* and /etc/pam.d/*

Configuration Information

Configuration information is placed in /etc/pam.d/. Here is a sample file:

# Begin /etc/pam.d/other

auth            required        pam_unix.so     nullok
account         required        pam_unix.so
session         required        pam_unix.so
password        required        pam_unix.so     nullok

# End /etc/pam.d/other

Now create some generic configuration files. As the root user:

install -vdm755 /etc/pam.d &&
cat > /etc/pam.d/system-account << "EOF" &&
# Begin /etc/pam.d/system-account

account   required    pam_unix.so

# End /etc/pam.d/system-account
EOF

cat > /etc/pam.d/system-auth << "EOF" &&
# Begin /etc/pam.d/system-auth

auth      required    pam_unix.so

# End /etc/pam.d/system-auth
EOF

cat > /etc/pam.d/system-session << "EOF" &&
# Begin /etc/pam.d/system-session

session   required    pam_unix.so

# End /etc/pam.d/system-session
EOF

cat > /etc/pam.d/system-password << "EOF"
# Begin /etc/pam.d/system-password

# use sha512 hash for encryption, use shadow, and try to use any previously
# defined authentication token (chosen password) set by any prior module.
# Use the same number of rounds as shadow.
password  required    pam_unix.so       sha512 shadow try_first_pass \
                                        rounds=500000

# End /etc/pam.d/system-password
EOF

If you wish to enable strong password support, install libpwquality-1.4.5, and follow the instructions on that page to configure the pam_pwquality PAM module with strong password support.

Next, add a restrictive /etc/pam.d/other configuration file. With this file, programs that are PAM aware will not run unless a configuration file specifically for that application exists.

cat > /etc/pam.d/other << "EOF"
# Begin /etc/pam.d/other

auth        required        pam_warn.so
auth        required        pam_deny.so
account     required        pam_warn.so
account     required        pam_deny.so
password    required        pam_warn.so
password    required        pam_deny.so
session     required        pam_warn.so
session     required        pam_deny.so

# End /etc/pam.d/other
EOF

The PAM man page (man pam) provides a good starting point to learn about the several fields, and allowable entries. The Linux-PAM System Administrators’ Guide is recommended for additional information.

Important

You should now reinstall the Shadow-4.13 and Systemd-252 packages.

Contents

Installed Program: faillock, mkhomedir_helper, pam_namespace_helper, pam_timestamp_check, pwhistory_helper, unix_chkpwd and unix_update

Installed Libraries: libpam.so, libpamc.so and libpam_misc.so

Installed Directories: /etc/security, /usr/lib/security, /usr/include/security and /usr/share/doc/Linux-PAM-1.5.2

Short Descriptions

faillock displays and modifies the authentication failure record files

mkhomedir_helper is a helper binary that creates home directories

pam_namespace_helper is a helper program used to configure a private namespace for a user session

pwhistory_helper is a helper program that transfers password hashes from passwd or shadow to opasswd

pam_timestamp_check is used to check if the default timestamp is valid

unix_chkpwd is a helper binary that verifies the password of the current user

unix_update is a helper binary that updates the password of a given user

libpam.so provides the interfaces between applications and the PAM modules.

4.13 liboauth-1.0.3

Introduction to liboauth

liboauth is a collection of POSIX-C functions implementing the OAuth Core RFC 5849 standard. Liboauth provides functions to escape and encode parameters according to OAuth specification and offers high-level functionality to sign requests or verify OAuth signatures as well as perform HTTP requests.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

liboauth Dependencies

Required

cURL-7.88.1

Optional

nss-3.88.1 and Doxygen-1.9.6 (to build documentation)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/liboauth

Installation of liboauth

Apply a patch for the current version of openssl:

patch -Np1 -i ../liboauth-1.0.3-openssl-1.1.0-3.patch

Install liboauth by running the following commands:

./configure --prefix=/usr --disable-static &&
make

If you wish to build the documentation (needs Doxygen-1.9.6), issue:

make dox

To test the results, issue: make check.

Now, as the root user:

make install

If you have previously built the documentation, install it by running the following commands as the root user:

install -v -dm755 /usr/share/doc/liboauth-1.0.3 &&
cp -rv doc/html/* /usr/share/doc/liboauth-1.0.3

Command Explanations

--disable-static: This switch prevents installation of static versions of the libraries.

--enable-nss: Use this switch if you want to use Mozilla NSS instead of OpenSSL.

Contents

Installed Programs: None

Installed Libraries: liboauth.so

Installed Directories: /usr/share/doc/liboauth-1.0.3

Short Descriptions

liboauth.so provides functions to escape and encode strings according to OAuth specifications and offers high-level functionality built on top to sign requests or verify signatures using either NSS or OpenSSL for calculating the hash/signatures.

4.14 libpwquality-1.4.5

Introduction to libpwquality

The libpwquality package provides common functions for password quality checking and also scoring them based on their apparent randomness. The library also provides a function for generating random passwords with good pronounceability.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

libpwquality Dependencies

Required

CrackLib-2.9.8

Linux-PAM-1.5.2

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/libpwquality

Installation of libpwquality

Install libpwquality by running the following commands:

./configure --prefix=/usr                      \
            --disable-static                   \
            --with-securedir=/usr/lib/security \
            --with-python-binary=python3       &&
make

This package does not come with a test suite.

Now, as the root user:

make install

Command Explanations

--with-python-binary=python3: This parameter gives the location of the Python binary. The default is python, and requires Python-2.7.18.

Configuring libpwquality

libpwquality is intended to be a functional replacement for the now-obsolete pam_cracklib.so PAM module. To configure the system to use the pam_pwquality module, execute the following commands as the root user:

mv /etc/pam.d/system-password{,.orig} &&
cat > /etc/pam.d/system-password << "EOF"
# Begin /etc/pam.d/system-password

# check new passwords for strength (man pam_pwquality)
password  required    pam_pwquality.so   authtok_type=UNIX retry=1 difok=1 \
                                         minlen=8 dcredit=0 ucredit=0 \
                                         lcredit=0 ocredit=0 minclass=1 \
                                         maxrepeat=0 maxsequence=0 \
                                         maxclassrepeat=0 gecoscheck=0 \
                                         dictcheck=1 usercheck=1 \
                                         enforcing=1 badwords="" \
                                         dictpath=/usr/lib/cracklib/pw_dict
# use sha512 hash for encryption, use shadow, and use the
# authentication token (chosen password) set by pam_pwquality
# above (or any previous modules). Also set the number of crypt rounds
# to the value used in shadow.
password  required    pam_unix.so        sha512 shadow use_authtok \
                                         rounds=500000

# End /etc/pam.d/system-password
EOF

Contents

Installed Programs: pwscore and pwmake

Installed Libraries: pam_pwquality.so and libpwquality.so

Installed Directories: None

Short Descriptions

pwmake is a simple configurable tool for generating random and relatively easily pronounceable passwords

pwscore is a simple tool for checking quality of a password

libpwquality.so contains API functions for checking the password quality

pam_pwquality.so is a Linux PAM module used to perform password quality checking.

4.15 MIT Kerberos V5-1.20.1

Introduction to MIT Kerberos V5

MIT Kerberos V5 is a free implementation of Kerberos 5. Kerberos is a network authentication protocol. It centralizes the authentication database and uses kerberized applications to work with servers or services that support Kerberos allowing single logins and encrypted communication over internal networks or the Internet.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

MIT Kerberos V5 Dependencies

Optional

BIND Utilities-9.18.12, GnuPG-2.4.0 (to authenticate the package), keyutils-1.6.1, OpenLDAP-2.6.4, Valgrind-3.20.0 (used during the test suite), yasm-1.3.0, libedit, cmocka, kdcproxy, pyrad, and resolv_wrapper

Note

Some sort of time synchronization facility on your system (like ntp-4.2.8p15) is required since Kerberos won’t authenticate if there is a time difference between a kerberized client and the KDC server.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/mitkrb

Installation of MIT Kerberos V5

Build MIT Kerberos V5 by running the following commands:

cd src &&

sed -i -e '/eq 0/{N;s/12 //}'    plugins/kdb/db2/libdb2/test/run.test &&
sed -i '/t_kadm5.py/d'           lib/kadm5/Makefile.in                &&

./configure --prefix=/usr            \
            --sysconfdir=/etc        \
            --localstatedir=/var/lib \
            --runstatedir=/run       \
            --with-system-et         \
            --with-system-ss         \
            --with-system-verto=no   \
            --enable-dns-for-realm &&
make

To test the build, issue as the root user: make -k -j1 check. Some tests may fail with the latest version of dejagnu and glibc. Some tests may hang for a long time and fail if the system is not connected to a network.

Now, as the root user:

make install &&

install -v -dm755 /usr/share/doc/krb5-1.20.1 &&
cp -vfr ../doc/*  /usr/share/doc/krb5-1.20.1

Command Explanations

The two sed commands remove tests that are known to fail.

--localstatedir=/var/lib: This option is used so that the Kerberos variable runtime data is located in /var/lib instead of /usr/var.

--runstatedir=/run: This option is used so that the Kerberos runtime state information is located in /run instead of the deprecated /var/run.

--with-system-et: This switch causes the build to use the system-installed versions of the error-table support software.

--with-system-ss: This switch causes the build to use the system-installed versions of the subsystem command-line interface software.

--with-system-verto=no: This switch fixes a bug in the package: it does not recognize its own verto library installed previously. This is not a problem, if reinstalling the same version, but if you are updating, the old library is used as system’s one, instead of installing the new version.

--enable-dns-for-realm: This switch allows realms to be resolved using the DNS server.

--with-ldap: Use this switch if you want to compile the OpenLDAP database backend module.

Configuring MIT Kerberos V5

Config Files

/etc/krb5.conf and /var/lib/krb5kdc/kdc.conf

Configuration Information

Kerberos Configuration

Tip

You should consider installing some sort of password checking dictionary so that you can configure the installation to only accept strong passwords. A suitable dictionary to use is shown in the CrackLib-2.9.8 instructions. Note that only one file can be used, but you can concatenate many files into one. The configuration file shown below assumes you have installed a dictionary to /usr/share/dict/words.

Create the Kerberos configuration file with the following commands issued by the root user:

cat > /etc/krb5.conf << "EOF"
# Begin /etc/krb5.conf

[libdefaults]
    default_realm = <EXAMPLE.ORG>
    encrypt = true

[realms]
    <EXAMPLE.ORG> = {
        kdc = <belgarath.example.org>
        admin_server = <belgarath.example.org>
        dict_file = /usr/share/dict/words
    }

[domain_realm]
    .<example.org> = <EXAMPLE.ORG>

[logging]
    kdc = SYSLOG:INFO:AUTH
    admin_server = SYSLOG:INFO:AUTH
    default = SYSLOG:DEBUG:DAEMON

# End /etc/krb5.conf
EOF

You will need to substitute your domain and proper hostname for the occurrences of the <belgarath> and <example.org> names.

default_realm should be the name of your domain changed to ALL CAPS. This isn’t required, but both Heimdal and MIT recommend it.

encrypt = true provides encryption of all traffic between kerberized clients and servers. It’s not necessary and can be left off. If you leave it off, you can encrypt all traffic from the client to the server using a switch on the client program instead.

The [realms] parameters tell the client programs where to look for the KDC authentication services.

The [domain_realm] section maps a domain to a realm.

Create the KDC database:

kdb5_util create -r <EXAMPLE.ORG> -s

Now you should populate the database with principals (users). For now, just use your regular login name or root.

kadmin.local
kadmin.local: add_policy dict-only
kadmin.local: addprinc -policy dict-only <loginname>

The KDC server and any machine running kerberized server daemons must have a host key installed:

kadmin.local: addprinc -randkey host/<belgarath.example.org>

After choosing the defaults when prompted, you will have to export the data to a keytab file:

kadmin.local: ktadd host/<belgarath.example.org>

This should have created a file in /etc named krb5.keytab (Kerberos 5). This file should have 600 (root rw only) permissions. Keeping the keytab files from public access is crucial to the overall security of the Kerberos installation.

Exit the kadmin program (use quit or exit) and return back to the shell prompt. Start the KDC daemon manually, just to test out the installation:

/usr/sbin/krb5kdc

Attempt to get a ticket with the following command:

kinit <loginname>

You will be prompted for the password you created. After you get your ticket, you can list it with the following command:

klist

Information about the ticket should be displayed on the screen.

To test the functionality of the keytab file, issue the following command as the root user:

ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l

This should dump a list of the host principal, along with the encryption methods used to access the principal.

Create an empty ACL file that can be modified later:

touch /var/lib/krb5kdc/kadm5.acl

At this point, if everything has been successful so far, you can feel fairly confident in the installation and configuration of the package.

Additional Information

For additional information consult the documentation for krb5-1.20.1 on which the above instructions are based.

Systemd Unit

If you want to start Kerberos services at boot, install the krb5.service unit included in the blfs-systemd-units-20220720 package using the following command:

make install-krb5

Contents

Installed Programs: gss-client, gss-server, k5srvutil, kadmin, kadmin.local, kadmind, kdb5_ldap_util (optional), kdb5_util, kdestroy, kinit, klist, kpasswd, kprop, kpropd, kproplog, krb5-config, krb5-send-pr, krb5kdc, ksu, kswitch, ktutil, kvno, sclient, sim_client, sim_server, sserver, uuclient, and uuserver

Installed Libraries: libgssapi_krb5.so, libgssrpc.so, libk5crypto.so, libkadm5clnt_mit.so, libkadm5clnt.so, libkadm5srv_mit.so, libkadm5srv.so, libkdb_ldap.so (optional), libkdb5.so, libkrad.so, libkrb5.so, libkrb5support.so, libverto.so, and some plugins under the /usr/lib/krb5 tree

Installed Directories: /usr/include/{gssapi,gssrpc,kadm5,krb5}, /usr/lib/krb5, /usr/share/{doc/krb5-1.20.1,examples/krb5}, /var/lib/krb5kdc, and /run/krb5kdc

Short Descriptions

gss-client is a GSSAPI test client

gss-server is a GSSAPI test server

k5srvutil is a host keytable manipulation utility

kadmin is an utility used to make modifications to the Kerberos database

kadmin.local is an utility similar to kadmin, but if the database is db2, the local client kadmin.local, is intended to run directly on the master KDC without Kerberos authentication

kadmind is a server for administrative access to a Kerberos database

kdb5_ldap_util (optional) allows an administrator to manage realms, Kerberos services and ticket policies

kdb5_util is the KDC database utility

kdestroy removes the current set of tickets

kinit is used to authenticate to the Kerberos server as a principal and acquire a ticket granting ticket that can later be used to obtain tickets for other services

klist reads and displays the current tickets in the credential cache

kpasswd is a program for changing Kerberos 5 passwords

kprop takes a principal database in a specified format and converts it into a stream of database records

kpropd receives a database sent by kprop and writes it as a local database

kproplog displays the contents of the KDC database update log to standard output

krb5-config gives information on how to link programs against libraries

krb5kdc is the Kerberos 5 server

krb5-send-pr sends a problem report (PR) to a central support site

ksu is the super user program using Kerberos protocol. Requires a properly configured /etc/shells and ~/.k5login containing principals authorized to become super users

kswitch makes the specified credential cache the primary cache for the collection, if a cache collection is available

ktutil is a program for managing Kerberos keytabs

kvno prints keyversion numbers of Kerberos principals

sclient is used to contact a sample server and authenticate to it using Kerberos 5 tickets, then display the server’s response

sim_client is a simple UDP-based sample client program, for demonstration

sim_server is a simple UDP-based server application, for demonstration

sserver is the sample Kerberos 5 server

uuclient is another sample client

uuserver is another sample server

libgssapi_krb5.so contains the Generic Security Service Application Programming Interface (GSSAPI) functions which provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments

libkadm5clnt.so contains the administrative authentication and password checking functions required by Kerberos 5 client-side programs

libkadm5srv.so contains the administrative authentication and password checking functions required by Kerberos 5 servers

libkdb5.so is a Kerberos 5 authentication/authorization database access library

libkrad.so contains the internal support library for RADIUS functionality

libkrb5.so is an all-purpose Kerberos 5 library.

4.16 Nettle-3.8.1

Introduction to Nettle

The Nettle package contains a low-level cryptographic library that is designed to fit easily in many contexts.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Nettle Dependencies

Optional

Valgrind-3.20.0 (optional for the tests)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/nettle

Installation of Nettle

Install Nettle by running the following commands:

./configure --prefix=/usr --disable-static &&
make

To test the results, issue: make check.

Now, as the root user:

make install &&
chmod   -v   755 /usr/lib/lib{hogweed,nettle}.so &&
install -v -m755 -d /usr/share/doc/nettle-3.8.1 &&
install -v -m644 nettle.html /usr/share/doc/nettle-3.8.1

Command Explanations

--disable-static: This switch prevents installation of static versions of the libraries.

Contents

Installed Programs: nettle-hash, nettle-lfib-stream, nettle-pbkdf2, pkcs1-conv and sexp-conv

Installed Libraries: libhogweed.so and libnettle.so

Installed Directory: /usr/include/nettle and /usr/share/doc/nettle-3.8.1

Short Descriptions

nettle-hash calculates a hash value using a specified algorithm

nettle-lfib-stream outputs a sequence of pseudorandom (non-cryptographic) bytes, using Knuth’s lagged fibonacci generator. The stream is useful for testing, but should not be used to generate cryptographic keys or anything else that needs real randomness

nettle-pbkdf2 is a password-based key derivation function that takes a password or a passphrase as input and returns a strengthened password, which is protected against pre-computation attacks by using salting and other expensive computations.

pkcs1-conv converts private and public RSA keys from PKCS #1 format to sexp format

sexp-conv converts an s-expression to a different encoding.

4.17 NSS-3.88.1

Introduction to NSS

The Network Security Services (NSS) package is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. This is useful for implementing SSL and S/MIME or other Internet security standards into an application.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

NSS Dependencies

Required

NSPR-4.35

SQLite-3.40.1 and p11-kit-0.24.1 (runtime)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/nss

Installation of NSS

Install NSS by running the following commands:

patch -Np1 -i ../nss-3.88.1-standalone-1.patch &&

patch -Np1 -i ../nss-3.88.1-standalone-1.patch &&

cd nss &&

make BUILD_OPT=1                  \
  NSPR_INCLUDE_DIR=/usr/include/nspr  \
  USE_SYSTEM_ZLIB=1                   \
  ZLIB_LIBS=-lz                       \
  NSS_ENABLE_WERROR=0                 \
  $([ $(uname -m) = x86_64 ] && echo USE_64=1) \
  $([ -f /usr/include/sqlite3.h ] && echo NSS_USE_SYSTEM_SQLITE=1)

To run the tests, execute the following commands:

cd tests &&
HOST=localhost DOMSUF=localdomain ./all.sh
cd ../

Note

Some information about the tests:

Now, as the root user:

cd ../dist                                                          &&

install -v -m755 Linux*/lib/*.so              /usr/lib              &&
install -v -m644 Linux*/lib/{*.chk,libcrmf.a} /usr/lib              &&

install -v -m755 -d                           /usr/include/nss      &&
cp -v -RL {public,private}/nss/*              /usr/include/nss      &&
chmod -v 644                                  /usr/include/nss/*    &&

install -v -m755 Linux*/bin/{certutil,nss-config,pk12util} /usr/bin &&

install -v -m644 Linux*/lib/pkgconfig/nss.pc  /usr/lib/pkgconfig

Command Explanations

BUILD_OPT=1: This option is passed to make so that the build is performed with no debugging symbols built into the binaries and the default compiler optimizations are used.

NSPR_INCLUDE_DIR=/usr/include/nspr: This option sets the location of the nspr headers.

USE_SYSTEM_ZLIB=1: This option is passed to make to ensure that the libssl3.so library is linked to the system installed zlib instead of the in-tree version.

ZLIB_LIBS=-lz: This option provides the linker flags needed to link to the system zlib.

$([ $(uname -m) = x86_64 ] && echo USE_64=1): The USE_64=1 option is required on x86_64, otherwise make will try (and fail) to create 32-bit objects. The [ $(uname -m) = x86_64 ] test ensures it has no effect on a 32 bit system.

([ -f /usr/include/sqlite3.h ] && echo NSS_USE_SYSTEM_SQLITE=1): This tests if sqlite is installed and if so it echos the option NSS_USE_SYSTEM_SQLITE=1 to make so that libsoftokn3.so will link against the system version of sqlite.

NSS_DISABLE_GTESTS=1: If you don’t need to run NSS test suite, append this option to make command, to prevent the compilation of tests and save some build time.

Configuring NSS

If p11-kit-0.24.1 is installed, the p11-kit trust module (/usr/lib/pkcs11/p11-kit-trust.so) can be used as a drop-in replacement for /usr/lib/libnssckbi.so to transparently make the system CAs available to NSS aware applications, rather than the static list provided by /usr/lib/libnssckbi.so. As the root user, execute the following command:

ln -sfv ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so

Additionally, for dependent applications that do not use the internal database (/usr/lib/libnssckbi.so), the /usr/sbin/make-ca script included on the make-ca-1.12 page can generate a system wide NSS DB with the -n switch, or by modifying the /etc/make-ca/make-ca.conf file.

Contents

Installed Programs: certutil, nss-config, and pk12util

Installed Libraries: libcrmf.a, libfreebl3.so, libfreeblpriv3.so, libnss3.so, libnssckbi.so, libnssckbi-testlib.so, libnssdbm3.so, libnsssysinit.so, libnssutil3.so, libpkcs11testmodule.so, libsmime3.so, libsoftokn3.so, and libssl3.so

Installed Directories: /usr/include/nss

Short Descriptions

certutil is the Mozilla Certificate Database Tool. It is a command-line utility that can create and modify the Netscape Communicator cert8.db and key3.db database files. It can also list, generate, modify, or delete certificates within the cert8.db file and create or change the password, generate new public and private key pairs, display the contents of the key database, or delete key pairs within the key3.db file

nss-config is used to determine the NSS library settings of the installed NSS libraries

pk12util is a tool for importing certificates and keys from pkcs #12 files into NSS or exporting them. It can also list certificates and keys in such files.

4.18 OpenSSH-9.2p1

Introduction to OpenSSH

The OpenSSH package contains ssh clients and the sshd daemon. This is useful for encrypting authentication and subsequent traffic over a network. The ssh and scp commands are secure implementations of telnet and rcp respectively.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

OpenSSH Dependencies

Optional

GDB-13.1 (for tests), Linux-PAM-1.5.2, a graphical environment, MIT Kerberos V5-1.20.1, Which-2.21 (for tests), libedit, LibreSSL Portable, OpenSC, and libsectok

Optional Runtime (Used only to gather entropy)

Net-tools-2.10, and Sysstat-12.7.2

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/OpenSSH

Installation of OpenSSH

OpenSSH runs as two processes when connecting to other computers. The first process is a privileged process and controls the issuance of privileges as necessary. The second process communicates with the network. Additional installation steps are necessary to set up the proper environment, which are performed by issuing the following commands as the root user:

install  -v -m700 -d /var/lib/sshd &&
chown    -v root:sys /var/lib/sshd &&

groupadd -g 50 sshd        &&
useradd  -c 'sshd PrivSep' \
         -d /var/lib/sshd  \
         -g sshd           \
         -s /bin/false     \
         -u 50 sshd

Install OpenSSH by running the following commands:

./configure --prefix=/usr                            \
            --sysconfdir=/etc/ssh                    \
            --with-privsep-path=/var/lib/sshd        \
            --with-default-path=/usr/bin             \
            --with-superuser-path=/usr/sbin:/usr/bin \
            --with-pid-dir=/run                      &&
make

The test suite requires an installed copy of scp to complete the multiplexing tests. To run the test suite, first copy the scp program to /usr/bin, making sure that you backup any existing copy first.

To test the results, issue: make -j1 tests.

Now, as the root user:

make install &&
install -v -m755    contrib/ssh-copy-id /usr/bin     &&

install -v -m644    contrib/ssh-copy-id.1 \
                    /usr/share/man/man1              &&
install -v -m755 -d /usr/share/doc/openssh-9.2p1     &&
install -v -m644    INSTALL LICENCE OVERVIEW README* \
                    /usr/share/doc/openssh-9.2p1

Command Explanations

--sysconfdir=/etc/ssh: This prevents the configuration files from being installed in /usr/etc.

--with-default-path=/usr/bin and --with-superuser-path=/usr/sbin:/usr/bin: These set PATH consistent with LFS and BLFS Shadow package.

--with-pid-dir=/run: This prevents OpenSSH from referring to deprecated /var/run.

--with-pam: This parameter enables Linux-PAM support in the build.

--with-xauth=/usr/bin/xauth: Set the default location for the xauth binary for X authentication. Change the location if xauth will be installed to a different path. This can also be controlled from sshd_config with the XAuthLocation keyword. You can omit this switch if Xorg is already installed.

--with-kerberos5=/usr: This option is used to include Kerberos 5 support in the build.

--with-libedit: This option enables line editing and history features for sftp.

Configuring OpenSSH

Config Files

~/.ssh/*, /etc/ssh/ssh_config, and /etc/ssh/sshd_config

There are no required changes to any of these files. However, you may wish to view the /etc/ssh/ files and make any changes appropriate for the security of your system. One recommended change is that you disable root login via ssh. Execute the following command as the root user to disable root login via ssh:

echo "PermitRootLogin no" >> /etc/ssh/sshd_config

If you want to be able to log in without typing in your password, first create ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub with ssh-keygen and then copy ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the remote computer that you want to log into. You’ll need to change REMOTE_USERNAME and REMOTE_HOSTNAME for the username and hostname of the remote computer and you’ll also need to enter your password for the ssh-copy-id command to succeed:

ssh-keygen &&
ssh-copy-id -i ~/.ssh/id_rsa.pub REMOTE_USERNAME@REMOTE_HOSTNAME

Once you’ve got passwordless logins working it’s actually more secure than logging in with a password (as the private key is much longer than most people’s passwords). If you would like to now disable password logins, as the root user:

echo "PasswordAuthentication no" >> /etc/ssh/sshd_config &&
echo "KbdInteractiveAuthentication no" >> /etc/ssh/sshd_config

If you added Linux-PAM support and you want ssh to use it then you will need to add a configuration file for sshd and enable use of LinuxPAM. Note, ssh only uses PAM to check passwords, if you’ve disabled password logins these commands are not needed. If you want to use PAM, issue the following commands as the root user:

sed 's@d/login@d/sshd@g' /etc/pam.d/login > /etc/pam.d/sshd &&
chmod 644 /etc/pam.d/sshd &&
echo "UsePAM yes" >> /etc/ssh/sshd_config

Additional configuration information can be found in the man pages for sshd, ssh and ssh-agent.

Systemd Unit

To start the SSH server at system boot, install the sshd.service unit included in the blfs-systemd-units-20220720 package.

make install-sshd

Contents

Installed Programs: scp, sftp, ssh, ssh-add, ssh-agent, ssh-copy-id, ssh-keygen, ssh-keyscan, and sshd

Installed Libraries: None

Installed Directories: /etc/ssh, /usr/share/doc/openssh-9.2p1, and /var/lib/sshd

Short Descriptions

scp is a file copy program that acts like rcp except it uses an encrypted protocol

sftp is an FTP-like program that works over the SSH1 and SSH2 protocols

ssh is an rlogin/rsh-like client program except it uses an encrypted protocol

sshd is a daemon that listens for ssh login requests

ssh-add is a tool which adds keys to the ssh-agent

ssh-agent is an authentication agent that can store private keys

ssh-copy-id is a script that enables logins on remote machines using local keys

ssh-keygen is a key generation tool

ssh-keyscan is a utility for gathering public host keys from a number of hosts.

4.19 p11-kit-0.24.1

Introduction to p11-kit

The p11-kit package provides a way to load and enumerate PKCS #11 (a Cryptographic Token Interface Standard) modules.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

p11-kit Dependencies

libtasn1-4.19.0 and make-ca-1.12 (runtime)

Optional

GTK-Doc-1.33.2, libxslt-1.1.37, and nss-3.88.1 (runtime)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/p11-kit

Installation of p11-kit

Prepare the distribution specific anchor hook:

sed '20,$ d' -i trust/trust-extract-compat &&
cat >> trust/trust-extract-compat << "EOF"
# Copy existing anchor modifications to /etc/ssl/local
/usr/libexec/make-ca/copy-trust-modifications

# Update trust stores
/usr/sbin/make-ca -r
EOF

Install p11-kit by running the following commands:

mkdir p11-build &&
cd    p11-build &&

meson --prefix=/usr       \
      --buildtype=release \
      -Dtrust_paths=/etc/pki/anchors &&
ninja

To test the results, issue: ninja test.

Now, as the root user:

ninja install &&
ln -sfv /usr/libexec/p11-kit/trust-extract-compat \
        /usr/bin/update-ca-certificates

Command Explanations

--buildtype=release: Specify a buildtype suitable for stable releases of the package, as the default may produce unoptimized binaries.

-Dtrust_paths=/etc/pki/anchors: this switch sets the location of trusted certificates used by libp11-kit.so.

-Dhash_impl=freebl: Use this switch if you want to use the Freebl library from NSS for SHA1 and MD5 hashing.

-Dgtk_doc=true: Use this switch if you have installed GTK-Doc-1.33.2 and libxslt-1.1.37 and wish to rebuild the documentation and generate manual pages.

Configuring p11-kit

The p11-kit trust module (/usr/lib/pkcs11/p11-kit-trust.so) can be used as a drop-in replacement for /usr/lib/libnssckbi.so to transparently make the system CAs available to NSS aware applications, rather than the static list provided by /usr/lib/libnssckbi.so. As the root user, execute the following commands:

ln -sfv ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so

Contents

Installed Programs: p11-kit, trust, and update-ca-certificates

Installed Libraries: libp11-kit.so and p11-kit-proxy.so

Installed Directories: /etc/pkcs11, /usr/include/p11-kit-1, /usr/lib/pkcs11, /usr/libexec/p11-kit, /usr/share/gtk-doc/html/p11-kit, and /usr/share/p11-kit

Short Descriptions

p11-kit is a command line tool that can be used to perform operations on PKCS#11 modules configured on the system

trust is a command line tool to examine and modify the shared trust policy store

update-ca-certificates is a command line tool to both extract local certificates from an updated anchor store, and regenerate all anchors and certificate stores on the system. This is done unconditionally on BLFS using the --force and --get flags to make-ca and should likely not be used for automated updates

libp11-kit.so contains functions used to coordinate initialization and finalization of any PKCS#11 module

p11-kit-proxy.so is the PKCS#11 proxy module.

4.20 Polkit-122

Introduction to Polkit

Polkit is a toolkit for defining and handling authorizations. It is used for allowing unprivileged processes to communicate with privileged processes.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Polkit Dependencies

Required

GLib-2.74.5 and duktape-2.7.0

gobject-introspection-1.74.0, libxslt-1.1.37, Linux-PAM-1.5.2

Note

Since systemd-logind uses PAM to register user sessions, it is a good idea to build Polkit with PAM support so systemd-logind can track Polkit sessions.

Optional

GTK-Doc-1.33.2, JS-102.8.0 (can be used in place of duktape), and dbusmock-0.28.7 (for tests)

Required Runtime Dependencies

Systemd-252

Optional Runtime Dependencies

One polkit authentication agent for using polkit in the graphical environment: polkit-kde-agent in Plasma-5.26.5 for KDE, the agent built in gnome-shell-43.3 for GNOME3, polkit-gnome-0.105 for XFCE, and lxpolkit in LXSession-0.5.5 for LXDE

Note

If libxslt-1.1.37 is installed, then docbook-xml-4.5 and docbook-xsl-nons-1.79.2 are required. If you have installed libxslt-1.1.37, but you do not want to install any of the DocBook packages mentioned, you will need to use -Dman=false in the instructions below.

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/polkit

Installation of Polkit

There should be a dedicated user and group to take control of the polkitd daemon after it is started. Issue the following commands as the root user:

groupadd -fg 27 polkitd &&
useradd -c "PolicyKit Daemon Owner" -d /etc/polkit-1 -u 27 \
        -g polkitd -s /bin/false polkitd

Install Polkit by running the following commands:

mkdir build &&
cd    build &&

meson --prefix=/usr                       \
      --buildtype=release                 \
      -Dman=true                          \
      -Dsession_tracking=libsystemd-login \
      -Dtests=true                        \
      -Djs_engine=duktape                 \
      ..                                  &&
ninja

To test the results, first ensure that the system D-Bus daemon is running, and both D-Bus Python-1.3.2 and dbusmock-0.28.7 are installed. Then run meson test -t3.

Now, as the root user:

ninja install

Command Explanations

--buildtype=release: Specify a buildtype suitable for stable releases of the package, as the default may produce unoptimized binaries.

-Dtests=true: This switch allows to run the test suite of this package. As Polkit is used for authorizations, its integrity can affect system security. So it’s recommended to run the test suite building this package.

-Djs_engine=duktape: This switch allows using the duktape-2.7.0 JavaScript engine. Replace with -Djs_engine=mozjs for using the JS-102.8.0 JavaScript engine.

-Dauthfw=shadow: This switch enables the package to use the Shadow rather than the Linux PAM Authentication framework. Use it if you have not installed Linux PAM.

-Dintrospection=false: Use this option if you are certain that you do not need gobject-introspection files for polkit, or do not have gobject-introspection installed.

-Dman=false: Use this option to disable generating and installing manual pages. This is useful if libxslt is not installed.

-Dexamples=true: Use this option to build the example programs.

-Dgtk_doc=true: Use this option to enable building and installing the API documentation.

Configuring Polkit

PAM Configuration

Note

If you did not build Polkit with Linux PAM support, you can skip this section.

If you have built Polkit with Linux PAM support, you need to modify the default PAM configuration file which was installed by default to get Polkit to work correctly with BLFS. Issue the following commands as the root user to create the configuration file for Linux PAM:

cat > /etc/pam.d/polkit-1 << "EOF"
# Begin /etc/pam.d/polkit-1

auth     include        system-auth
account  include        system-account
password include        system-password
session  include        system-session

# End /etc/pam.d/polkit-1
EOF

Contents

Installed Programs: pkaction, pkcheck, pkexec, pkttyagent, and polkitd

Installed Libraries: libpolkit-agent-1.so and libpolkit-gobject-1.so

Installed Directories: /etc/polkit-1, /usr/include/polkit-1, /usr/lib/polkit-1, /usr/share/gtk-doc/html/polkit-1, and /usr/share/polkit-1

Short Descriptions

pkaction is used to obtain information about registered PolicyKit actions

pkcheck is used to check whether a process is authorized for action

pkexec allows an authorized user to execute a command as another user

pkttyagent is used to start a textual authentication agent for the subject

polkitd provides the org.freedesktop.PolicyKit1 D-Bus service on the system message bus

libpolkit-agent-1.so contains the Polkit authentication agent API functions

libpolkit-gobject-1.so contains the Polkit authorization API functions.

4.21 polkit-gnome-0.105

Introduction to Polkit GNOME

The Polkit GNOME package provides an Authentication Agent for Polkit that integrates well with the GNOME Desktop environment.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Additional Downloads

Polkit GNOME Dependencies

Required

AccountsService-22.08.8, GTK+-3.24.36, and Polkit-122

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/polkit-gnome

Installation of Polkit GNOME

First, apply some fixes that allow for the proper user icon to be used, as well as some security fixes:

patch -Np1 -i ../polkit-gnome-0.105-consolidated_fixes-1.patch

Install Polkit GNOME by running the following commands:

./configure --prefix=/usr &&
make

This package does not come with a test suite.

Now, as the root user:

make install

Configuring Polkit GNOME

Automatic Startup

For the authentication framework to work, polkit-gnome-authentification-agent-1 needs to be started. However, make install did not install a startup file for the Polkit GNOME so you have to create it by yourself.

Issue the following commands as the root user to create a startup file for Polkit GNOME:

mkdir -p /etc/xdg/autostart &&
cat > /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop << "EOF"
[Desktop Entry]
Name=PolicyKit Authentication Agent
Comment=PolicyKit Authentication Agent
Exec=/usr/libexec/polkit-gnome-authentication-agent-1
Terminal=false
Type=Application
Categories=
NoDisplay=true
OnlyShowIn=GNOME;XFCE;Unity;
AutostartCondition=GNOME3 unless-session gnome
EOF

Contents

Installed Program: polkit-gnome-authentication-agent-1

Installed Libraries: None

Installed Directory: None

Short Descriptions

polkit-gnome-authentication-agent-1 is the Polkit authentication agent.

4.22 Shadow-4.13

Introduction to Shadow

Shadow was indeed installed in LFS and there is no reason to reinstall it unless you installed CrackLib or Linux-PAM after your LFS system was completed. If you have installed CrackLib after LFS, then reinstalling Shadow will enable strong password support. If you have installed Linux-PAM, reinstalling Shadow will allow programs such as login and su to utilize PAM.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Shadow Dependencies

Required

Linux-PAM-1.5.2 or CrackLib-2.9.8

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/shadow

Installation of Shadow

Important

The installation commands shown below are for installations where Linux-PAM has been installed and Shadow is being reinstalled to support the Linux-PAM installation.

If you are reinstalling Shadow to provide strong password support using the CrackLib library without using Linux-PAM, ensure you add the --with-libcrack parameter to the configure script below and also issue the following command:

sed -i 's@DICTPATH.*@DICTPATH\t/lib/cracklib/pw_dict@' etc/login.defs

Reinstall Shadow by running the following commands:

sed -i 's/groups$(EXEEXT) //' src/Makefile.in          &&

find man -name Makefile.in -exec sed -i 's/groups\.1 / /'   {} \; &&
find man -name Makefile.in -exec sed -i 's/getspnam\.3 / /' {} \; &&
find man -name Makefile.in -exec sed -i 's/passwd\.5 / /'   {} \; &&

sed -e 's@#ENCRYPT_METHOD DES@ENCRYPT_METHOD SHA512@' \
    -e 's@#\(SHA_CRYPT_..._ROUNDS 5000\)@\100@'       \
    -e 's@/var/spool/mail@/var/mail@'                 \
    -e '/PATH=/{s@/sbin:@@;s@/bin:@@}'                \
    -i etc/login.defs                                 &&

./configure --sysconfdir=/etc               \
            --disable-static                \
            --with-group-name-max-length=32 &&
make

This package does not come with a test suite.

Now, as the root user:

make exec_prefix=/usr install

The man pages were installed in LFS, but if reinstallation is desired, run (as the root user):

make -C man install-man

Command Explanations

sed -i ‘s/groups$(EXEEXT) //’ src/Makefile.in: This sed is used to suppress the installation of the groups program as the version from the Coreutils package installed during LFS is preferred.

find man -name Makefile.in -exec … {} \;: The first command is used to suppress the installation of the groups man pages so the existing ones installed from the Coreutils package are not replaced. The two other commands prevent installation of manual pages that are already installed by Man-pages in LFS.

sed -e ‘s@#ENCRYPT_METHOD DES@ENCRYPT_METHOD SHA512@’ -e ‘s@#(SHA_CRYPT_…_ROUNDS 5000)@\100@’ -e ‘s@/var/spool/mail@/var/mail@’ -e ‘/PATH=/{s@/sbin:@@;s@/bin:@@}’ -i etc/login.defs: Instead of using the default ‘DES’ method, this command modifies the installation to use the more secure ‘SHA512’ method of hashing passwords, which also allows passwords longer than eight characters. The number of rounds is also increased to prevent brute force password attacks. The command also changes the obsolete /var/spool/mail location for user mailboxes that Shadow uses by default to the /var/mail location. It also changes the default path to be consistent with that set in LFS.

--with-group-name-max-length=32: The maximum user name is 32 characters. Make the maximum group name the same.

Configuring Linux-PAM to Work with Shadow

Note

The rest of this page is devoted to configuring Shadow to work properly with Linux-PAM. If you do not have Linux-PAM installed, and you reinstalled Shadow to support strong passwords via the CrackLib library, no further configuration is required.

Config Files

/etc/pam.d/* or alternatively /etc/pam.conf, /etc/login.defs and /etc/security/*

Configuration Information

Configuring your system to use Linux-PAM can be a complex task. The information below will provide a basic setup so that Shadow’s login and password functionality will work effectively with Linux-PAM. Review the information and links on the Linux-PAM-1.5.2 page for further configuration information. For information specific to integrating Shadow, Linux-PAM and libpwquality, you can visit the following link:

Configuring /etc/login.defs

The login program currently performs many functions which Linux-PAM modules should now handle. The following sed command will comment out the appropriate lines in /etc/login.defs, and stop login from performing these functions (a backup file named /etc/login.defs.orig is also created to preserve the original file’s contents). Issue the following commands as the root user:

install -v -m644 /etc/login.defs /etc/login.defs.orig &&
for FUNCTION in FAIL_DELAY               \
                FAILLOG_ENAB             \
                LASTLOG_ENAB             \
                MAIL_CHECK_ENAB          \
                OBSCURE_CHECKS_ENAB      \
                PORTTIME_CHECKS_ENAB     \
                QUOTAS_ENAB              \
                CONSOLE MOTD_FILE        \
                FTMP_FILE NOLOGINS_FILE  \
                ENV_HZ PASS_MIN_LEN      \
                SU_WHEEL_ONLY            \
                CRACKLIB_DICTPATH        \
                PASS_CHANGE_TRIES        \
                PASS_ALWAYS_WARN         \
                CHFN_AUTH ENCRYPT_METHOD \
                ENVIRON_FILE
do
    sed -i "s/^${FUNCTION}/# &/" /etc/login.defs
done
Configuring the /etc/pam.d/ Files

As mentioned previously in the Linux-PAM instructions, Linux-PAM has two supported methods for configuration. The commands below assume that you’ve chosen to use a directory based configuration, where each program has its own configuration file. You can optionally use a single /etc/pam.conf configuration file by using the text from the files below, and supplying the program name as an additional first field for each line.

As the root user, create the following Linux-PAM configuration files in the /etc/pam.d/ directory (or add the contents to the /etc/pam.conf file) using the following commands:

‘login’
cat > /etc/pam.d/login << "EOF"
# Begin /etc/pam.d/login

# Set failure delay before next prompt to 3 seconds
auth      optional    pam_faildelay.so  delay=3000000

# Check to make sure that the user is allowed to login
auth      requisite   pam_nologin.so

# Check to make sure that root is allowed to login
# Disabled by default. You will need to create /etc/securetty
# file for this module to function. See man 5 securetty.
#auth      required    pam_securetty.so

# Additional group memberships - disabled by default
#auth      optional    pam_group.so

# include system auth settings
auth      include     system-auth

# check access for the user
account   required    pam_access.so

# include system account settings
account   include     system-account

# Set default environment variables for the user
session   required    pam_env.so

# Set resource limits for the user
session   required    pam_limits.so

# Display date of last login - Disabled by default
#session   optional    pam_lastlog.so

# Display the message of the day - Disabled by default
#session   optional    pam_motd.so

# Check user's mail - Disabled by default
#session   optional    pam_mail.so      standard quiet

# include system session and password settings
session   include     system-session
password  include     system-password

# End /etc/pam.d/login
EOF
‘passwd’
cat > /etc/pam.d/passwd << "EOF"
# Begin /etc/pam.d/passwd

password  include     system-password

# End /etc/pam.d/passwd
EOF
‘su’
cat > /etc/pam.d/su << "EOF"
# Begin /etc/pam.d/su

# always allow root
auth      sufficient  pam_rootok.so

# Allow users in the wheel group to execute su without a password
# disabled by default
#auth      sufficient  pam_wheel.so trust use_uid

# include system auth settings
auth      include     system-auth

# limit su to users in the wheel group
# disabled by default
#auth      required    pam_wheel.so use_uid

# include system account settings
account   include     system-account

# Set default environment variables for the service user
session   required    pam_env.so

# include system session settings
session   include     system-session

# End /etc/pam.d/su
EOF
‘chpasswd’ and ‘newusers’
cat > /etc/pam.d/chpasswd << "EOF"
# Begin /etc/pam.d/chpasswd

# always allow root
auth      sufficient  pam_rootok.so

# include system auth and account settings
auth      include     system-auth
account   include     system-account
password  include     system-password

# End /etc/pam.d/chpasswd
EOF

sed -e s/chpasswd/newusers/ /etc/pam.d/chpasswd >/etc/pam.d/newusers
‘chage’
cat > /etc/pam.d/chage << "EOF"
# Begin /etc/pam.d/chage

# always allow root
auth      sufficient  pam_rootok.so

# include system auth and account settings
auth      include     system-auth
account   include     system-account

# End /etc/pam.d/chage
EOF
Other shadow utilities
for PROGRAM in chfn chgpasswd chsh groupadd groupdel \
               groupmems groupmod useradd userdel usermod
do
    install -v -m644 /etc/pam.d/chage /etc/pam.d/${PROGRAM}
    sed -i "s/chage/$PROGRAM/" /etc/pam.d/${PROGRAM}
done

Warning

At this point, you should do a simple test to see if Shadow is working as expected. Open another terminal and log in as root, and then run login and login as another user. If you do not see any errors, then all is well and you should proceed with the rest of the configuration. If you did receive errors, stop now and double check the above configuration files manually. Any error is the sign of an error in the above procedure. You can also run the test suite from the Linux-PAM package to assist you in determining the problem. If you cannot find and fix the error, you should recompile Shadow adding the --without-libpam switch to the configure command in the above instructions (also move the /etc/login.defs.orig backup file to /etc/login.defs). If you fail to do this and the errors remain, you will be unable to log into your system.

Configuring Login Access

Instead of using the /etc/login.access file for controlling access to the system, Linux-PAM uses the pam_access.so module along with the /etc/security/access.conf file. Rename the /etc/login.access file using the following command:

if [ -f /etc/login.access ]; then mv -v /etc/login.access{,.NOUSE}; fi
Configuring Resource Limits

Instead of using the /etc/limits file for limiting usage of system resources, Linux-PAM uses the pam_limits.so module along with the /etc/security/limits.conf file. Rename the /etc/limits file using the following command:

if [ -f /etc/limits ]; then mv -v /etc/limits{,.NOUSE}; fi

Caution

Be sure to test the login capabilities of the system before logging out. Errors in the configuration can cause a permanent lockout requiring a boot from an external source to correct the problem.

Contents

A list of the installed files, along with their short descriptions can be found at lfs/view/11.3-systemd/chapter08/shadow.html#contents-shadow.

4.23 ssh-askpass-9.2p1

Introduction to ssh-askpass

The ssh-askpass is a generic executable name for many packages, with similar names, that provide a interactive X service to grab password for packages requiring administrative privileges to be run. It prompts the user with a window box where the necessary password can be inserted. Here, we choose Damien Miller’s package distributed in the OpenSSH tarball.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

ssh-askpass Dependencies

Required

GTK+-3.24.36, Sudo-1.9.13p1 (runtime), Xorg Libraries, and a graphical environment (runtime)

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/ssh-askpass

Installation of ssh-askpass

Install ssh-askpass by running the following commands:

cd contrib &&
make gnome-ssh-askpass3

Now, as the root user:

install -v -d -m755                    /usr/libexec/openssh/contrib  &&
install -v -m755    gnome-ssh-askpass3 /usr/libexec/openssh/contrib  &&
ln -sv -f contrib/gnome-ssh-askpass3   /usr/libexec/openssh/ssh-askpass

The use of /usr/libexec/openssh/contrib and a symlink is justified by the eventual necessity of a different program for that service.

Configuring ssh-askpass

Configuration Information

As the root user, configure Sudo-1.9.13p1 to use ssh-askpass:

cat >> /etc/sudo.conf << "EOF" &&
# Path to askpass helper program
Path askpass /usr/libexec/openssh/ssh-askpass
EOF
chmod -v 0644 /etc/sudo.conf

If a given graphical requires administrative privileges, use **sudo -A ** from an x-terminal, from a Window Manager menu and/or replace "Exec= ..." by "Exec=sudo -A ..." in the .desktop file.

Contents

Installed Programs: gnome-ssh-askpass3, ssh-askpass (symlink to gnome-ssh-askpass3)

Installed Library: None

Installed Directory: /usr/libexec/openssh/contrib.

4.24 stunnel-5.68

Introduction to stunnel

The stunnel package contains a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer) so you can easily communicate with clients over secure channels. stunnel can also be used to tunnel PPP over network sockets without changes to the server package source code.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

stunnel Dependencies

Optional

libnsl-2.0.0, netcat (required for tests), tcpwrappers, and TOR

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/stunnel

Installation of stunnel

The stunnel daemon will be run in a chroot jail by an unprivileged user. Create the new user and group using the following commands as the root user:

groupadd -g 51 stunnel &&
useradd -c "stunnel Daemon" -d /var/lib/stunnel \
        -g stunnel -s /bin/false -u 51 stunnel

Note

A signed SSL Certificate and a Private Key is necessary to run the stunnel daemon. After the package is installed, there are instructions to generate them. However, if you own or have already created a signed SSL Certificate you wish to use, copy it to /etc/stunnel/stunnel.pem before starting the build (ensure only root has read and write access). The .pem file must be formatted as shown below:

-----BEGIN PRIVATE KEY-----
<many encrypted lines of private key>
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
<many encrypted lines of certificate>
-----END CERTIFICATE-----
-----BEGIN DH PARAMETERS-----
<encrypted lines of dh parms>
-----END DH PARAMETERS-----

Install stunnel by running the following commands:

./configure --prefix=/usr        \
            --sysconfdir=/etc    \
            --localstatedir=/var &&
make

If you have installed the optional netcat application, the regression tests can be run with make check.

Now, as the root user:

make docdir=/usr/share/doc/stunnel-5.68 install

Install the included systemd unit by running the following command as the root user:

install -v -m644 tools/stunnel.service /usr/lib/systemd/system

If you do not already have a signed SSL Certificate and Private Key, create the stunnel.pem file in the /etc/stunnel directory using the command below. You will be prompted to enter the necessary information. Ensure you reply to the

Common Name (FQDN of your server) [localhost]:

prompt with the name or IP address you will be using to access the service(s).

To generate a certificate, as the root user, issue:

make cert

Command Explanations

make docdir=… install: This command installs the package and changes the documentation installation directory to standard naming conventions.

Configuring stunnel

Config Files

/etc/stunnel/stunnel.conf

Configuration Information

As the root user, create the directory used for the .pid file created when the stunnel daemon starts:

install -v -m750 -o stunnel -g stunnel -d /var/lib/stunnel/run &&
chown stunnel:stunnel /var/lib/stunnel

Next, create a basic /etc/stunnel/stunnel.conf configuration file using the following commands as the root user:

cat > /etc/stunnel/stunnel.conf << "EOF"
; File: /etc/stunnel/stunnel.conf

; Note: The pid and output locations are relative to the chroot location.

pid    = /run/stunnel.pid
chroot = /var/lib/stunnel
client = no
setuid = stunnel
setgid = stunnel
cert   = /etc/stunnel/stunnel.pem

;debug = 7
;output = stunnel.log

;[https]
;accept  = 443
;connect = 80
;; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SSL
;; Microsoft implementations do not use SSL close-notify alert and thus
;; they are vulnerable to truncation attacks
;TIMEOUTclose = 0

EOF

Finally, add the service(s) you wish to encrypt to the configuration file. The format is as follows:

[<service>]
accept  = <hostname:portnumber>
connect = <hostname:portnumber>

For a full explanation of the commands and syntax used in the configuration file, issue man stunnel.

Systemd Unit

To start the stunnel daemon at boot, enable the previously installed systemd unit by running the following command as the root user:

systemctl enable stunnel

Contents

Installed Programs: stunnel and stunnel3

Installed Library: libstunnel.so

Installed Directories: /{etc,lib,var/lib}/stunnel and /usr/share/doc/stunnel-5.68

Short Descriptions

stunnel is a program designed to work as an SSL encryption wrapper between remote clients and local or remote servers

stunnel3 is a Perl wrapper script to use stunnel 3.x syntax with stunnel 4.05 or later

libstunnel.so contains the API functions required by stunnel.

4.25 Sudo-1.9.13p1

Introduction to Sudo

The Sudo package allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Sudo Dependencies

Optional

Linux-PAM-1.5.2, MIT Kerberos V5-1.20.1, OpenLDAP-2.6.4, MTA (that provides a sendmail command), AFS, FWTK, and Opie

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/sudo

Installation of Sudo

Install Sudo by running the following commands:

./configure --prefix=/usr              \
            --libexecdir=/usr/lib      \
            --with-secure-path         \
            --with-all-insults         \
            --with-env-editor          \
            --docdir=/usr/share/doc/sudo-1.9.13p1 \
            --with-passprompt="[sudo] password for %p: " &&
make
To test the results, issue: **env LC_ALL=C make check 2>&1 tee make-check.log. Check the results with **grep failed make-check.log.

Now, as the root user:

make install &&
ln -sfv libsudo_util.so.0.0.0 /usr/lib/sudo/libsudo_util.so.0

Command Explanations

--libexecdir=/usr/lib: This switch controls where private programs are installed. Everything in that directory is a library, so they belong under /usr/lib instead of /usr/libexec.

--with-secure-path: This switch transparently adds /sbin and /usr/sbin directories to the PATH environment variable.

--with-all-insults: This switch includes all the sudo insult sets.

--with-env-editor: This switch enables use of the environment variable EDITOR for visudo.

--with-passprompt: This switch sets the password prompt. The %p will be expanded to the name of the user whose password is being requested.

--without-pam: This switch avoids building Linux-PAM support when Linux-PAM is installed on the system.

Note

There are many options to sudo’s configure command. Check the configure –help output for a complete list.

ln -sfv libsudo_util…: Works around a bug in the installation process, which links to the previously installed version (if there is one) instead of the new one.

Configuring Sudo

Config File

/etc/sudoers

Configuration Information

The sudoers file can be quite complicated. It is composed of two types of entries: aliases (basically variables) and user specifications (which specify who may run what). The installation installs a default configuration that has no privileges installed for any user.

A couple of common configuration changes are to set the path for the super user and to allow members of the wheel group to execute all commands after providing their own credientials. Use the following commands to create the /etc/sudoers.d/00-sudo configuration file as the root user:

cat > /etc/sudoers.d/00-sudo << "EOF"
Defaults secure_path="/usr/sbin:/usr/bin"
%wheel ALL=(ALL) ALL
EOF

Note

In very simple installations where there is only one user, it may be easier to just edit the /etc/sudoers file directly. In that case, the secure_path entry may not be needed and using sudo -E … can import the non-privileged user’s full environment into the privileged session.

The files in the /etc/sudoers.d directory are parsed in sorted lexical order. Be careful that entries in an added file do not overwrite previous entries.

For details, see man sudoers.

Note

The Sudo developers highly recommend using the visudo program to edit the sudoers file. This will provide basic sanity checking like syntax parsing and file permission to avoid some possible mistakes that could lead to a vulnerable configuration.

If PAM is installed on the system, Sudo is built with PAM support. In that case, issue the following command as the root user to create the PAM configuration file:

cat > /etc/pam.d/sudo << "EOF"
# Begin /etc/pam.d/sudo

# include the default auth settings
auth      include     system-auth

# include the default account settings
account   include     system-account

# Set default environment variables for the service user
session   required    pam_env.so

# include system session defaults
session   include     system-session

# End /etc/pam.d/sudo
EOF
chmod 644 /etc/pam.d/sudo

Contents

Installed Programs: cvtsudoers, sudo, sudo_logsrvd, sudo_sendlog, sudoedit (symlink), sudoreplay, and visudo

Installed Libraries: audit_json.so, group_file.so, libsudo_util.so, sample_approval.so, sudoers.so, sudo_noexec.so, and system_group.so

Installed Directories: /etc/sudoers.d, /usr/lib/sudo, /usr/share/doc/sudo-1.9.13p1, and /var/lib/sudo

Short Descriptions

cvtsudoers converts between sudoers file formats

sudo executes a command as another user as permitted by the /etc/sudoers configuration file

sudo_logsrvd is a sudo event and I/O log server

sudo_sendlog sends sudo I/O logs to the log server

sudoedit is a symlink to sudo that implies the -e option to invoke an editor as another user

sudoreplay is used to play back or list the output logs created by sudo

visudo allows for safer editing of the sudoers file.

4.26 Tripwire-2.4.3.7

Introduction to Tripwire

The Tripwire package contains programs used to verify the integrity of the files on a given system.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

Tripwire Dependencies

Optional

An MTA

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/tripwire

Installation of Tripwire

Compile Tripwire by running the following commands:

sed -e '/^CLOBBER/s/false/true/'         \
    -e 's|TWDB="${prefix}|TWDB="/var|'   \
    -e '/TWMAN/ s|${prefix}|/usr/share|' \
    -e '/TWDOCS/s|${prefix}/doc/tripwire|/usr/share/doc/tripwire-2.4.3.7|' \
    -i installer/install.cfg                               &&

find . -name Makefile.am | xargs                           \
    sed -i 's/^[[:alpha:]_]*_HEADERS.*=/noinst_HEADERS =/' &&

sed '/dist/d' -i man/man?/Makefile.am                      &&
autoreconf -fi                                             &&

./configure --prefix=/usr --sysconfdir=/etc/tripwire       &&
make CPPFLAGS=-std=c++11

Note

The default configuration is to use a local MTA. If you don’t have an MTA installed and have no wish to install one, modify install/install.cfg to use an SMTP server instead. Otherwise the install will fail.

This package does not come with a test suite.

Now, as the root user:

make install &&
cp -v policy/*.txt /usr/share/doc/tripwire-2.4.3.7

Note

During make install, several questions are asked, including passwords. If you want to make a script, you have to apply a sed before running make install:

sed -i -e 's@installer/install.sh@& -n -s <site-password> -l <local-password>@' Makefile

Of course, you should do this with dummy passwords and change them later.

Another issue when scripting is that the installer exits when the standard input is not a terminal. You may disable this behavior with the following sed:

sed '/-t 0/,+3d' -i installer/install.sh

Command Explanations

sed … installer/install.cfg: This command tells the package to install the program database and reports in /var/lib/tripwire and sets the proper location for man pages and documentation.

find …, sed …, and autoreconf -fi: The build system is unusable as is, and has to be modified for the build to succeed.

CPPFLAGS=-std=c++11: Setting the C++ preprocessor flags to version 11 is necessary to prevent a conflict with the default version which is c++17 in recent version of gcc.

make install: This command creates the Tripwire security keys as well as installing the binaries. There are two keys: a site key and a local key which are stored in /etc/tripwire/.

cp -v policy/*.txt /usr/doc/tripwire-2.4.3.7: This command installs the tripwire sample policy files with the other tripwire documentation.i

Configuring Tripwire

Config Files

/etc/tripwire/*

Configuration Information

Tripwire uses a policy file to determine which files are integrity checked. The default policy file (/etc/tripwire/twpol.txt) is for a default installation and will need to be updated for your system.

Policy files should be tailored to each individual distribution and/or installation. Some example policy files can be found in /usr/share/doc/tripwire/.

If desired, copy the policy file you’d like to try into /etc/tripwire/ instead of using the default policy file, twpol.txt. It is, however, recommended that you edit your policy file. Get ideas from the examples above and read /usr/share/doc/tripwire/policyguide.txt for additional information. twpol.txt is a good policy file for learning about Tripwire as it will note any changes to the file system and can even be used as an annoying way of keeping track of changes for uninstallation of software.

After your policy file has been edited to your satisfaction you may begin the configuration steps (perform as the root) user:

twadmin --create-polfile --site-keyfile /etc/tripwire/site.key \
    /etc/tripwire/twpol.txt &&
tripwire --init

Depending on your system and the contents of the policy file, the initialization phase above can take a relatively long time.

Usage Information

Tripwire will identify file changes in the critical system files specified in the policy file. Using Tripwire while making frequent changes to these directories will flag all these changes. It is most useful after a system has reached a configuration that the user considers stable.

To use Tripwire after creating a policy file to run a report, use the following command:

tripwire --check > /etc/tripwire/report.txt

View the output to check the integrity of your files. An automatic integrity report can be produced by using a cron facility to schedule the runs.

Reports are stored in binary and, if desired, encrypted. View reports, as the root user, with:

twprint --print-report -r /var/lib/tripwire/report/<report-name.twr>

After you run an integrity check, you should examine the report (or email) and then modify the Tripwire database to reflect the changed files on your system. This is so that Tripwire will not continually notify you hat files you intentionally changed are a security violation. To do this you must first ls -l /var/lib/tripwire/report/ and note the name of the newest file which starts with your system name as presented by the command uname -n and ends in .twr. These files were created during report creation and the most current one is needed to update the Tripwire database of your system. As the root user, type in the following command making the appropriate report name:

tripwire --update --twrfile /var/lib/tripwire/report/<report-name.twr>

You will be placed into Vim with a copy of the report in front of you. If all the changes were good, then just type :wq and after entering your local key, the database will be updated. If there are files which you still want to be warned about, remove the ‘x’ before the filename in the report and type :wq.

Changing the Policy File

If you are unhappy with your policy file and would like to modify it or use a new one, modify the policy file and then execute the following commands as the root user:

twadmin --create-polfile /etc/tripwire/twpol.txt &&
tripwire --init

Contents

Installed Programs: siggen, tripwire, twadmin, and twprint

Installed Libraries: None

Installed Directories: /etc/tripwire, /var/lib/tripwire, and /usr/share/doc/tripwire-2.4.3.7

Short Descriptions

siggen is a signature gathering utility that displays the hash function values for the specified files

tripwire is the main file integrity checking program

twadmin administrative and utility tool used to perform certain administrative functions related to Tripwire files and configuration options

twprint prints Tripwire database and report files in clear text format.

4.27 volume_key-0.3.12

Introduction to volume_key

The volume_key package provides a library for manipulating storage volume encryption keys and storing them separately from volumes to handle forgotten passphrases.

This package is known to build and work properly using an LFS 11.3 platform.

Package Information

volume_key Dependencies

Required

cryptsetup-2.4.3, GLib-2.74.5, GnuPG-2.4.0, GPGME-1.18.0, and nss-3.88.1

SWIG-4.1.1

User Notes: https://wiki.linuxfromscratch.org/blfs/wiki/volume_key

Installation of volume_key

Note

This package expands to the directory volume_key-volume_key-0.3.12.

Tell the building system how to locate GPGME and GnuPG correctly:

sed -e '/AM_PATH_GPGME/iAM_PATH_GPG_ERROR' \
    -e 's/gpg2/gpg/' -i configure.ac

Install volume_key by running the following commands:

autoreconf -fiv              &&
./configure --prefix=/usr    \
            --without-python &&
make

To test the results, issue: make check.

Now, as the root user:

make install

Command Explanations

--without-python: This parameter prevents building the Python 2 bindings, if Python-2.7.18 is installed.

--without-python3: Use this option if you do not want to build the Python 3 bindings. In this case, SWIG-4.1.1 is not needed.

Contents

Installed Program: volume_key

Installed Library: libvolume_key.so

Installed Directory: /usr/include/volume_key

Short Descriptions

volume_key manages encrypted volume keys and passphrases

volume_key.so contains API functions for managing encrypted volume keys.