everything about linux distro and not only
The previous chapter covered resource limits with ulimit, which constrains what a process can consume. This chapter covers the kernel parameters that control how the operating system itself behaves under load. The sysctl command is the interface to the kernel’s tunable parameters. These parameters live in the /proc/sys virtual filesystem and control networking stacks, memory…
SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) system implemented in the Linux kernel. Unlike the traditional discretionary access control (DAC) model, where the file owner decides who can access a resource, SELinux uses a security policy that the system enforces regardless of the user’s identity or the file’s permissions . Every process, file,…
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…
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 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 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 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 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 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 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,…