Unit 5: SELinux and Advanced Storage Management - Subjective Questions

Security-Enhanced Linux (SELinux) is a mandatory access control framework integrated into the Linux kernel. It supplements traditional discretionary access control permissions such as file ownership and rwx permissions.

SELinux improves security through the following mechanisms:

• Mandatory access control: Access is governed by a system-wide security policy rather than only by file owners.
• Process confinement: Services and applications run inside restricted security domains.
• Least privilege: A process receives only the permissions required for its intended operation.
• Label-based decisions: SELinux assigns security contexts to processes, files, ports, and other resources.
• Damage containment: If a confined service is compromised, SELinux limits the files and resources that it can access.
• Auditing: Denied operations are recorded in audit logs, allowing administrators to investigate security violations.

For example, a compromised web server process may still be prevented from reading files labeled for user home directories, even when ordinary UNIX permissions would otherwise allow access.

SELinux supports three operating modes:

• Enforcing mode:

  • SELinux policy is active.
  • Operations that violate the policy are blocked.
  • Policy violations are recorded in audit logs.
  • This is the recommended mode for production systems.

• Permissive mode:

  • SELinux policy is evaluated but violations are not blocked.
  • Access Vector Cache denial messages, commonly called AVC denials, are logged.
  • This mode is useful for troubleshooting and policy development.

• Disabled mode:

  • SELinux policy is not loaded or enforced.
  • SELinux labels may not be maintained correctly while the system is disabled.
  • Re-enabling SELinux may require a complete file-system relabel.

Enforcing and permissive modes keep SELinux active, while disabled mode removes SELinux protection entirely.

The current SELinux status can be inspected using getenforce or sestatus.

Temporary mode change:

• Run setenforce 0 to change from enforcing to permissive mode.
• Run setenforce 1 to change from permissive to enforcing mode.
• The change takes effect immediately but is lost after a reboot.
• setenforce cannot enable SELinux when it has been completely disabled at boot.

Permanent mode change:

• Edit /etc/selinux/config.
• Set SELINUX=enforcing, SELINUX=permissive, or SELINUX=disabled as required.
• Reboot the system for the setting to take full effect.

Disabling SELinux is generally discouraged. When SELinux has been disabled and is later re-enabled, the administrator should arrange a file-system relabel, for example by creating /.autorelabel before rebooting.

An SELinux security context normally has the form user:role:type:level.

• SELinux user: Associates the object or process with an SELinux identity, such as system_u.
• Role: Identifies the SELinux role, such as object_r for files.
• Type: Defines the domain of a process or the type of an object. Type enforcement primarily uses this field when making access decisions.
• Level: Represents the Multi-Level Security or Multi-Category Security level, such as s0.

An example file context is system_u:object_r:httpd_sys_content_t:s0.

Useful commands include:

• ls -Z /path to display file contexts.
• ps -eZ to display process contexts.
• id -Z to display the current user's SELinux context.
• stat -c %C /path/file to inspect the context of a specific file.

Correct type labels are especially important because an incorrectly labeled file may be denied even when its standard Linux permissions are correct.

The three commands serve related but different purposes:

• chcon: Changes the current SELinux context directly on a file or directory. The change is usually temporary because a later relabel or restorecon operation can replace it with the policy-defined context.
• semanage fcontext: Adds or modifies a persistent file-context rule in the SELinux policy configuration. It defines which label should apply to a pathname or pathname pattern.
• restorecon: Applies the policy-defined default context to files and directories. The -R option processes a directory recursively, and -v displays changes.

For example, to assign web-content labels persistently to /srv/site and its contents:

1. Run semanage fcontext -a -t httpd_sys_content_t '/srv/site(/.*)?'.
2. Run restorecon -Rv /srv/site.

Thus, semanage fcontext records the durable rule, while restorecon applies that rule. chcon is more suitable for short-term testing.

SELinux Booleans are policy switches that enable or disable predefined optional behavior without requiring administrators to rewrite SELinux policy modules.

Useful commands include:

• getsebool -a lists all Booleans and their current values.
• getsebool boolean_name displays one Boolean.
• semanage boolean -l lists Booleans together with descriptions and default values.
• setsebool boolean_name on changes a Boolean for the running system.
• setsebool -P boolean_name on changes and persists the value across reboots.

For example, setsebool -P httpd_can_network_connect on permits confined web-server processes to initiate network connections when allowed by the associated policy.

Booleans should be enabled only when required. Although they are safer than disabling SELinux, they can broaden the permissions available to a confined service.

A systematic investigation should include the following steps:

1. Confirm the problem: Check whether ordinary ownership, permissions, ACLs, service configuration, and firewall rules are correct.
2. Inspect SELinux status: Use getenforce and sestatus to verify that SELinux is active.
3. Locate AVC records: Use ausearch -m AVC,USER_AVC -ts recent or inspect /var/log/audit/audit.log.
4. Interpret the denial: Pipe relevant audit messages to sealert when the troubleshooting tools are installed. Identify the source process type, target type, object class, and denied permission.
5. Check labels: Use ls -Z, ps -eZ, and matchpathcon to detect incorrectly labeled resources.
6. Apply an approved correction: Use restorecon, define a persistent rule with semanage fcontext, enable an appropriate Boolean, or correct a nonstandard port label with semanage port.
7. Retest in enforcing mode: Verify both the intended operation and the absence of new denials.

Generating a custom policy with audit2allow should be a last step after confirming that the requested access is legitimate. Blindly allowing every denial can weaken system security.

• A partition is a defined region of a storage device represented by a device file such as /dev/sdb1.
• A file system organizes data and metadata within a partition or logical volume. Common Linux file systems include XFS and ext4.
• A mount point is a directory through which the contents of a mounted file system become accessible.
• A persistent mount is configured to be mounted automatically during boot, usually through /etc/fstab.

These layers perform different functions. Partitioning allocates space, formatting creates the file-system structure, and mounting integrates that structure into the Linux directory tree.

Administrators commonly use lsblk, blkid, df -h, and findmnt to inspect these layers. Persistent mounts should normally use a file-system UUID rather than a device name because names such as /dev/sdb1 may change when hardware detection order changes.

A typical procedure is:

1. Use lsblk to identify the correct unused disk and confirm that it contains no required data.
2. Create a partition table and partition with a tool such as parted or fdisk.
3. Ask the kernel to reread the partition table with partprobe if necessary.
4. Verify the new partition using lsblk.
5. Create a file system, for example mkfs.xfs /dev/sdb1 or mkfs.ext4 /dev/sdb1.
6. Obtain the file-system UUID using blkid /dev/sdb1.
7. Create a mount-point directory, such as /data.
8. Add an entry to /etc/fstab, for example UUID=<uuid> /data xfs defaults 0 0.
9. Test the configuration with mount -a before rebooting.
10. Confirm the result using findmnt /data and df -h /data.

Testing mount -a is critical because an invalid /etc/fstab entry can delay or interrupt the next boot. The administrator should also set appropriate ownership, permissions, and SELinux contexts on the mounted content.

An /etc/fstab entry contains six fields:

1. Device or source: A UUID, label, device path, or another mount source.
2. Mount point: The directory where the file system is attached.
3. File-system type: For example, xfs, ext4, or swap.
4. Mount options: Options such as defaults, ro, noexec, _netdev, or nofail.
5. Dump field: Traditionally controls backup by the dump utility; it is commonly set to 0.
6. File-system check order: Controls boot-time fsck order. A value of 0 disables checking, 1 is normally reserved for the root file system, and 2 is used for other eligible file systems.

For example: UUID=abcd-1234 /data xfs defaults 0 0.

UUIDs identify file systems independently of device discovery order. They are therefore more stable than names such as /dev/sdb1, which can change after hardware or configuration changes.

Swap space is disk-backed virtual memory used when the kernel moves inactive memory pages out of physical RAM. It can also support hibernation on suitably configured systems, but it is much slower than RAM.

For a swap partition:

• Create or identify a partition.
• Run mkswap /dev/sdb2.
• Activate it with swapon /dev/sdb2.
• Add UUID=<uuid> none swap defaults 0 0 to /etc/fstab.

For a swap file:

• Allocate a file, for example with fallocate -l 2G /swapfile.
• Restrict access with chmod 600 /swapfile.
• Initialize it using mkswap /swapfile.
• Activate it using swapon /swapfile.
• Add /swapfile none swap defaults 0 0 to /etc/fstab.

The result can be verified using swapon --show and free -h. Administrators can deactivate swap with swapoff, provided sufficient memory is available.

Linux Logical Volume Manager, or LVM, introduces an abstraction layer between physical storage and file systems.

• A physical volume (PV) is a disk or partition initialized for LVM using pvcreate.
• A volume group (VG) combines one or more PVs into a shared storage pool.
• A physical extent (PE) is a fixed-size allocation unit into which VG storage is divided.
• A logical volume (LV) is a virtual block device allocated from the extents available in a VG.

The approximate capacity relationship is:

An LV can span multiple physical devices because LVM maps its logical extents to physical extents in the VG. File systems are created on LV device paths such as /dev/vgdata/lvfiles.

This design provides flexible allocation, online expansion in many cases, snapshots, and easier storage replacement compared with rigid fixed partitions.

The standard workflow is:

1. Initialize a device as a physical volume: pvcreate /dev/sdb1.
2. Create a volume group: vgcreate vgdata /dev/sdb1.
3. Create a logical volume: lvcreate -L 10G -n lvfiles vgdata.
4. Verify the LVM objects with pvs, vgs, and lvs.
5. Create a file system, for example mkfs.xfs /dev/vgdata/lvfiles.
6. Create the mount point: mkdir /files.
7. Obtain the UUID with blkid /dev/vgdata/lvfiles.
8. Add a suitable UUID-based entry to /etc/fstab.
9. Run mount -a and verify the mount using findmnt /files.

The administrator should confirm capacity requirements before allocating the LV and retain free space in the VG when future growth is expected. File ownership, permissions, and SELinux labels must also be configured for the intended service.

Before extending storage, the administrator should verify free volume-group space with vgs or vgdisplay and identify the correct logical volume and file system.

The LV can be extended with a command such as lvextend -L +5G /dev/vgdata/lvfiles. The file system must then be enlarged to use the added block space.

• XFS: Run xfs_growfs /mountpoint while the file system is mounted. XFS supports online growth but does not support shrinking.
• ext4: Run resize2fs /dev/vgdata/lvfiles. ext4 can generally be grown online when mounted; shrinking normally requires unmounting and careful offline preparation.

Alternatively, lvextend -r -L +5G /dev/vgdata/lvfiles asks LVM to extend the LV and resize a supported file system in one operation.

The final capacity should be checked with lvs, df -h, and file-system-specific tools. Reducing an LV is riskier than extending it because shrinking the block device before shrinking the file system can destroy data.

Traditional partitions divide a disk into fixed regions. They are simple, widely supported, and suitable for boot partitions, small systems, or storage layouts that rarely change. However, resizing and moving their boundaries can be difficult.

LVM logical volumes are allocated from volume groups that may contain multiple devices. Their advantages include:

• Flexible allocation from a shared storage pool.
• Easier online expansion.
• Ability to add physical volumes to increase pool capacity.
• Support for snapshots, thin provisioning, and selected RAID layouts.
• Descriptive device names such as /dev/vgdata/lvbackup.

LVM also adds management complexity and another metadata layer. Damage to volume-group metadata can affect multiple logical volumes, so reliable backups and configuration archives are important.

A common layout uses ordinary partitions for firmware or boot requirements and LVM for application data, user data, and file systems expected to grow.

LVM snapshots preserve a point-in-time view of an LV by tracking changed blocks. They are useful for consistent backups and short-term testing. A traditional snapshot consumes allocated copy-on-write space as the origin changes. If this space becomes full, the snapshot can become unusable. A snapshot is not an independent backup when it resides on the same failing storage.

Thin provisioning uses a thin pool from which virtual LVs are created. Logical sizes can exceed currently committed physical storage, and physical blocks are allocated as data is written.

Benefits of thin provisioning include:

• Efficient allocation for sparsely used volumes.
• Rapid creation of thin volumes and snapshots.
• Reduced initial physical-space consumption.

Limitations include:

• Thin-pool data and metadata usage must be monitored continuously.
• Over-provisioning can cause write failures if the pool becomes full.
• Pool metadata requires protection and recovery planning.

Both features improve flexibility, but neither removes the need for independent backups, monitoring, and tested recovery procedures.

Stratis is a local storage-management system designed to simplify advanced Linux storage configuration. It presents a management model based primarily on storage pools and file systems.

Its architecture includes:

• Block devices: Disks or other supported block devices supplied to Stratis.
• Pools: Managed storage collections created from one or more block devices.
• File systems: Thinly provisioned file systems created from pool capacity.
• stratisd: The service that manages Stratis storage.
• stratis command: The command-line interface used by administrators.

Internally, Stratis coordinates existing Linux storage technologies, including device-mapper components and XFS, while exposing a simpler interface. It supports features such as thin provisioning, snapshots, pool growth, and monitoring.

Stratis is useful when administrators need flexible local storage without manually coordinating each underlying layer. It is not a distributed file system and does not replace external backup or high-availability solutions.

A typical Stratis workflow is:

1. Install the required Stratis packages and enable stratisd.
2. Confirm that the selected device is unused and contains no required data.
3. Create a pool, for example stratis pool create datapool /dev/sdb.
4. Create a file system with stratis filesystem create datapool files.
5. Inspect the result using stratis pool list and stratis filesystem list.
6. Create a mount point such as /files.
7. Obtain the Stratis file-system UUID with blkid.
8. Add an /etc/fstab entry using the UUID and the x-systemd.requires=stratisd.service mount option where required by the distribution.
9. Test with mount -a and verify using findmnt.

To expand pool capacity, add another unused block device with a command such as stratis pool add-data datapool /dev/sdc. The pool can then allocate additional physical space to its thinly provisioned file systems as data is written. Pool usage must still be monitored to avoid exhausting physical capacity.

Virtual Data Optimizer (VDO) is a device-mapper storage technology that reduces physical storage usage. It creates a virtual block device that can be formatted directly or used as a lower layer for LVM.

VDO applies several techniques:

• Deduplication: Identical data blocks are stored once, and repeated logical blocks reference the existing physical block.
• Compression: Unique blocks are compressed before being written when compression produces a useful saving.
• Thin provisioning: Physical storage is allocated as logical data is written rather than reserving the entire virtual size immediately.

A conceptual reduction ratio can be expressed as:

For example, if of logical data occupies physically, the ratio is .

Actual savings depend heavily on the workload. Repeated virtual-machine images may deduplicate well, while encrypted, precompressed, or random data usually provides little benefit.

LVM provides flexible block-storage management through physical volumes, volume groups, and logical volumes. It supports features such as resizing, snapshots, RAID layouts, and thin provisioning.

Stratis provides a higher-level pool and file-system interface. It coordinates underlying Linux storage technologies to simplify thinly provisioned local storage, snapshots, and pool growth.

VDO focuses on data reduction through deduplication and compression while also supporting thin provisioning. On current systems it may be managed as an LVM VDO volume rather than as a separate standalone service.

All three can participate in layered storage designs, but each solves a different problem: LVM manages block allocation, Stratis simplifies storage pools and file systems, and VDO reduces repeated or compressible data.

When storage is over-provisioned, administrators must:

• Monitor physical allocation, metadata usage, and growth rates.
• Configure warning thresholds and automated alerts.
• Maintain reserve capacity for unexpected writes.
• Test behavior when capacity approaches exhaustion.
• Avoid advertising unrealistic virtual capacity.
• Keep independent backups and documented recovery procedures.

Running out of backing space can cause write failures, file-system errors, or service outages even when applications appear to have free logical capacity.