The previous chapter covered tar as the archiver for backups. This chapter covers rsync, which is the synchronization tool for backups. The distinction matters: tar produces a single archive file that must be extracted to be useful. rsync produces a mirror of the source directory that is immediately usable. The LFCS exam tests the rsync…

The previous chapter covered the conceptual backup strategies: the 3-2-1 rule, the RPO and RTO, and the distinction between full, incremental, and differential backups. This chapter covers the practical tool that implements those strategies on Linux: tar (Tape ARchive). Despite the name, tar is not just for tapes. It is the standard archiver for Linux,…

The previous chapters covered security and monitoring. This chapter shifts the focus to disaster recovery: the principles of backup that determine whether the data survives a disk failure, a ransomware attack, an accidental deletion, or a natural disaster. The LFCS exam tests the conceptual model: the 3-2-1 rule, the distinction between full, incremental, and differential…

The previous chapter covered AppArmor, which confines applications using path-based profiles. This chapter covers the system-wide audit framework: the kernel component that records security-relevant events and the auditd daemon that writes them to disk. Unlike AppArmor, which blocks actions, auditd observes and records. It does not prevent a file from being read; it records who…

The previous chapter introduced AppArmor’s conceptual model: path-based profiles attached to executables, with two enforcement modes. This chapter focuses on the practical mechanics of the profile files themselves and the operational workflow of switching between enforce and complain mode, reloading profiles after edits, and using the tooling to iterate on profile development. The LFCS exam…

The previous chapters covered SELinux, which is the default Mandatory Access Control (MAC) system on RHEL-family distributions. This chapter introduces AppArmor, which is the default MAC system on Ubuntu and SUSE. Both systems enforce a security policy that sits behind the traditional Unix permissions, but they use fundamentally different models. SELinux uses inode-based labels and…

The previous chapters covered the SELinux modes, contexts, and booleans. This chapter covers the workflow for diagnosing an access denial. An application fails, the logs show a denial, and the administrator must decide whether the cause is a mislabeled file, a boolean that needs to be toggled, a port that is not permitted, or a…

The previous chapter covered security contexts and labels: the data that the SELinux policy uses to identify files and processes. This chapter covers the switches that adjust the policy without recompiling it. A SELinux boolean is a named toggle that the policy checks at runtime. When the toggle is on, a specific rule or set…

The previous chapter introduced the SELinux modes: Enforcing, Permissive, and Disabled. This chapter covers the data that the policy actually evaluates: the security context. Every process, file, directory, and socket in a SELinux system carries a label, and the policy rules match on the type field of that label, not on the file path or…