Unit 5: SELinux and Advanced Storage Management

I. Security and Storage Foundations

Linux administration combines mandatory access control with layered storage management. SELinux supplements traditional permissions by enforcing policy-based access decisions, while partitions, file systems, LVM, Stratis, and VDO organize physical storage into usable, resilient, and efficient layers.

• Defense in depth: Access may require both standard UNIX permissions and an SELinux policy rule; permission from one mechanism does not override denial by the other.
• Persistent configuration: Runtime changes often disappear after reboot, so permanent settings belong in configuration files, policy databases, /etc/fstab, or storage metadata.
• Layered storage: A typical path is physical disk → partition → LVM physical volume → volume group → logical volume → file system → mount point.
• Stable identification: Persistent mounts should use UUIDs, labels, or managed device paths instead of changeable names such as /dev/sdb1.
• Online management: LVM and modern file systems support many capacity changes while mounted, but shrinking is more restrictive and risk-prone.
• Verification: Commands such as getenforce, lsblk, findmnt, pvs, vgs, and lvs confirm actual state after configuration.

II. SELinux Security

A. Managing SELinux Security

SELinux limits what processes can do by comparing security contexts against loaded policy rules.

• Security context: Every SELinux-aware process and object has a label commonly displayed as user:role:type:level, such as system_u:object_r:httpd_sys_content_t:s0.
  • Type: The main policy attribute used in targeted policy, for example httpd_t for an Apache process.
  • Level: Represents an MLS/MCS sensitivity and category set, commonly s0.
• Type enforcement: Policy might permit a process in httpd_t to read httpd_sys_content_t files while denying access to user_home_t.
• Policy modes: The common targeted policy confines selected network-facing services while leaving many ordinary processes unconfined.
• Inspection: Display labels with:

ps -eZ
ls -Z /var/www/html
id -Z

• Interaction with DAC: SELinux is checked after discretionary access control; a file normally needs suitable ownership/mode bits and an allowed SELinux rule.

B. Changing the SELinux Enforcement Mode

SELinux modes determine whether policy violations are blocked, merely logged, or not evaluated.

1. Runtime mode: setenforce switches between enforcing and permissive without rebooting.

getenforce
sudo setenforce 0   # permissive
sudo setenforce 1   # enforcing
sestatus

2. Persistent mode: /etc/selinux/config controls startup behavior.

SELINUX=enforcing
SELINUXTYPE=targeted

• Enforcing: Denied operations are blocked and usually recorded as AVC messages.
• Permissive: Violations are logged but allowed, making this mode useful for diagnosis.
• Disabled: SELinux policy is not active; changing to or from fully disabled generally requires rebooting and may require file-system relabeling.
• Preferred diagnosis: Use permissive mode temporarily instead of disabling SELinux, because permissive mode continues producing evidence.

C. Controlling SELinux File Contexts

Temporary context changes can test a diagnosis, but they do not alter SELinux’s persistent labeling rules.

• View labels: ls -Zd path shows the context of a file or directory.
• Temporary change: chcon changes the current extended attribute.

sudo chcon -t httpd_sys_content_t /srv/site/index.html

• Limitation: A later restorecon, relabel, or file recreation may replace a chcon label with the policy-defined default.
• Inheritance: Newly created files usually receive labels based on policy transition rules and the parent directory, not simply by copying an arbitrary source label.
• Copy behavior: Ordinary copies normally create destination objects with destination-appropriate labels; moves can preserve the source inode and its unsuitable label.

D. Controlling SELinux File Contexts

Persistent file-context control maps path patterns to required SELinux types and then applies those mappings.

• Persistent mapping: semanage fcontext stores local rules without directly relabeling existing files.

sudo semanage fcontext -a -t httpd_sys_content_t \
  '/srv/site(/.*)?'
sudo restorecon -Rv /srv/site

• Pattern meaning: '/srv/site(/.*)?' covers the directory and every descendant.
• Application: restorecon compares files with policy expectations and restores matching labels; -R recurses and -v reports changes.
• Equivalent mapping: Reuse another directory’s definitions with:

sudo semanage fcontext -a -e /var/www /srv/www
sudo restorecon -Rv /srv/www

• Verification: semanage fcontext -l lists definitions, while matchpathcon /srv/site/index.html predicts the expected label.

E. Adjusting SELinux Policy with Booleans

SELinux booleans expose predefined policy choices without requiring administrators to rewrite policy modules.

• Discovery: getsebool -a lists booleans; semanage boolean -l adds descriptions and persistent settings.
• Temporary setting: The following change lasts until reboot or policy reload:

sudo setsebool httpd_can_network_connect on

• Persistent setting: -P writes the policy customization:

sudo setsebool -P httpd_can_network_connect on

• Least privilege: Enable only the boolean matching the required behavior; broad access can increase a compromised service’s capabilities.
• Example: httpd_can_network_connect permits confined web-server processes to initiate network connections, which may be needed for a reverse proxy or database client.

F. Investigating and Resolving SELinux Issues

SELinux troubleshooting should identify the denied action before changing labels, booleans, or policy.

• Initial separation: Check ordinary permissions, ownership, ACLs, service configuration, and SELinux labels independently.
• Audit evidence: AVC denials usually appear in /var/log/audit/audit.log.

sudo ausearch -m AVC,USER_AVC -ts recent
sudo sealert -a /var/log/audit/audit.log

• Diagnostic sequence:
  1. Reproduce the failure and locate the matching denial.
  2. Compare the source process type, target object type, requested class, and permission.
  3. Correct an invalid label with semanage fcontext and restorecon.
  4. Enable an appropriate documented boolean when the requested behavior is optional policy functionality.
• Custom policy: audit2allow can suggest rules, but generated output must be reviewed; it may authorize symptoms of a configuration error.
• Permissive domains: Domain-specific permissive settings can isolate troubleshooting more narrowly than making the entire system permissive.

III. Basic Linux Storage

A. Managing Basic Storage and Logical Volumes

Storage management begins by identifying devices and deciding whether direct partitions or LVM flexibility best suit the workload.

• Inventory: lsblk -f shows devices, file-system types, UUIDs, and mount points; blkid reports persistent identifiers.
• Capacity view: df -hT reports mounted file-system usage, whereas du -sh directory totals visible files beneath a path.
• Direct storage: A file system placed directly on a partition is simple but less adaptable to later capacity changes.
• LVM storage: Physical volumes are combined into volume groups from which administrators allocate independently sized logical volumes.
• Safety: Confirm device names and backups before partitioning or formatting because mkfs, wipefs, and partition deletion can destroy metadata.

B. Adding Partitions, File Systems, and Persistent Mounts

A usable persistent disk requires a partition or logical device, a file system, a mount point, and a valid /etc/fstab entry.

• Partitioning: fdisk commonly manages MBR or GPT interactively; parted is suitable for scripted or large-disk GPT work.

sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart primary xfs 1MiB 100%
sudo partprobe /dev/sdb

• File-system creation: XFS is widely used for large scalable file systems, while ext4 supports both growing and offline shrinking.

sudo mkfs.xfs /dev/sdb1
sudo mkdir -p /data
sudo mount /dev/sdb1 /data

• Persistent mount: Obtain the UUID with blkid and add an /etc/fstab record:

UUID=2f00-example  /data  xfs  defaults  0  0

• Validation: Run mount -a and then findmnt /data; this exposes syntax or device errors before reboot.
• Mount options: Options such as noexec, nosuid, and nodev can reduce risk but may break applications that require those capabilities.

C. Managing Swap Space

Swap provides disk-backed virtual memory and may also support hibernation, but it is much slower than RAM.

• Inspection: swapon --show lists active swap; free -h summarizes RAM and swap consumption.
• Swap partition: Initialize and activate a dedicated device:

sudo mkswap /dev/sdb2
sudo swapon /dev/sdb2

• Swap file: A file is easier to resize or remove.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

• Persistence: Add /swapfile none swap defaults 0 0 to /etc/fstab.
• Removal: Run swapoff before deleting swap storage, and ensure enough RAM exists to absorb its active pages.
• Tuning: vm.swappiness influences preference for reclaiming memory through swap; it is not a percentage threshold for starting swap.

IV. Logical Volume Management

A. Creating Logical Volumes

LVM allocates logical devices from pooled physical storage, separating application volumes from physical disk boundaries.

• Physical volume: pvcreate /dev/sdb1 writes LVM metadata to the partition.
• Volume group: vgcreate vgdata /dev/sdb1 creates a storage pool named vgdata.
• Logical volume: Allocate a fixed amount or percentage:

sudo lvcreate -L 10G -n lvapp vgdata
sudo mkfs.xfs /dev/vgdata/lvapp
sudo mount /dev/vgdata/lvapp /app

• Extent allocation: LVM divides a volume group into physical extents, commonly 4 MiB each, and maps logical extents onto them.
• Monitoring: pvs, vgs, and lvs -a -o +devices show capacity, free extents, and device placement.
• Persistence: Use the logical volume’s UUID or /dev/mapper/vgdata-lvapp in /etc/fstab.

B. Extending Logical Volumes

Extending storage requires increasing the logical block device and then growing its file system.

• Available space: Confirm free volume-group capacity with vgs; add another physical volume with vgextend when necessary.
• LV extension: Add 5 GiB to a logical volume:

sudo lvextend -L +5G /dev/vgdata/lvapp

• File-system growth:
  • XFS: sudo xfs_growfs /app
  • ext4: sudo resize2fs /dev/vgdata/lvapp
• Combined operation: lvextend -r -L +5G device invokes the appropriate file-system resize helper.
• All remaining capacity: -l +100%FREE consumes every currently free extent, leaving no reserve for other volumes.
• Shrinking warning: XFS cannot be shrunk, and ext4 must normally be unmounted and reduced before the logical volume; reversing that order risks data loss.

V. Advanced Storage Features

A. Implementing Advanced Storage Features

Advanced storage layers add pooling, snapshots, thin provisioning, integrity, compression, or deduplication to basic block devices.

• Layer selection: Each layer solves a specific problem and adds metadata, memory, monitoring, and recovery requirements.
• Thin provisioning: Logical capacity may exceed physical allocation because blocks are reserved only when written; pool exhaustion must be monitored.
• Snapshots: Point-in-time block mappings support short-lived testing and backup coordination but are not independent backups.
• Discard support: fstrim or suitable discard configuration can inform lower layers that deleted blocks are no longer needed.
• Operational rule: Administrators should monitor both advertised logical capacity and real backing-store consumption.

B. Managing Layered Storage with Stratis

Stratis provides daemon-managed storage pools and file systems over block devices, using technologies such as device mapper and XFS.

• Components: stratisd performs management, while the stratis command-line tool controls pools and file systems.
• Pool creation:

sudo stratis pool create datapool /dev/sdb
sudo stratis filesystem create datapool records

• Persistent mounting: Obtain the Stratis file-system UUID and use _netdev in /etc/fstab so mounting waits for the storage service.

UUID=example  /records  xfs  defaults,x-systemd.requires=stratisd.service  0  0

• Expansion: stratis pool add-data datapool /dev/sdc adds capacity to the pool.
• Inspection: stratis pool list, stratis blockdev list, and stratis filesystem list expose each managed layer.
• Snapshots: Stratis can create file-system snapshots within a pool, but snapshots still depend on the same underlying pool.

C. Compressing and Deduplicating Storage with VDO

VDO reduces physical storage consumption through zero-block elimination, deduplication, and compression.

• Deduplication: Identical logical blocks are stored once and referenced through metadata; effectiveness depends on repeated block content.
• Compression: Unique blocks are compressed before physical storage, benefiting compressible data but adding CPU work.
• Provisioning: VDO may expose a logical size larger than its physical backing device, so physical utilization must be monitored continuously.
• LVM integration: On systems supporting LVM VDO, a VDO pool and virtual logical volume can be created with lvcreate --type vdo.
• Workload suitability: Virtual-machine images and repeated container data often deduplicate well; already compressed or encrypted data usually saves little space.
• Risk control: Reaching physical capacity can disrupt writes despite apparent logical free space; alerts and realistic capacity thresholds are essential.