How Linux+ differs from LFCS and RHCSA

Start Here / Guide 3 of 28 / Beginner

• PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
• git2.53.0 (Ubuntu) / 2.52.0 (AlmaLinux)
• Containerspodman 5.7.0 (Ubuntu) / 5.8.2 (AlmaLinux)
• TimeAbout 13 min

Domain names are CompTIA's published objectives for XK0-006. The comparison with RHCSA and LFCS is against those vendors' own published objectives, all linked below.

• Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
• Firewallufw / nftables 1.1.6 - firewalld / nftables 1.1.5

This guide includes

Use this when choosing between three overlapping Linux exams. This matters because containers are what Linux+ has and the others do not - and Domain 4 wants a capability, not a topic you have read about.

• checking that the tools Domain 4 assumes are actually there, on both families
• running a rootless container and leaving nothing behind
• meeting mandatory access control, which is not the same word on each family

Before you start

• the-lab-and-the-two-package-families

1. 1

   The tools Domain 4 assumes you have

   Check they are actually there, on both families.

   $git --version; podman --version; echo "--- Domain 4 needs both of these, and neither RHCSA 10 nor LFCS tests them"git version 2.52.0podman version 5.8.2--- Domain 4 needs both of these, and neither RHCSA 10 nor LFCS tests them$git --version; podman --version; echo "--- Domain 4 needs both of these, and neither RHCSA 10 nor LFCS tests them"git version 2.52.0podman version 5.8.2--- Domain 4 needs both of these, and neither RHCSA 10 nor LFCS tests them

   Expected resultgit and podman present on both machines - 2.53.0 and 5.7.0 on Ubuntu, 2.52.0 and 5.8.2 on AlmaLinux.

   Success conditionYou can see what this exam expects that the others do not.

2. 2

   Run a container, rootless, and leave nothing behind

   The Domain 4 capability, demonstrated rather than described.

   $podman run --rm docker.io/library/alpine:3.21 sh -c 'echo "a container ran, rootless, as $(id -un)"' 2>&1 | tail -3a container ran, rootless, as root$id -u; podman info --format '{{.Host.Security.Rootless}}' 2>/dev/null; echo "--- rootless: no root, no daemon"1000true--- rootless: no root, no daemon$podman ps -a --format '{{.Names}}' | wc -l; echo "containers left behind (0 means --rm did its job)"0containers left behind (0 means --rm did its job)

   Expected resultA container running as root INSIDE while the invoking user is not root outside, Rootless: true, and 0 containers left afterwards.

   Success conditionYou have run a container without privileges and cleaned up after it.

3. 3

   Mandatory access control, which is not the same word on each

   The Security domain is family-neutral; the implementations are not.

   $echo "is the mandatory access control layer on?"; aa-status --enabled 2>/dev/null && echo "AppArmor: enabled" || sudo aa-status 2>&1 | head -2is the mandatory access control layer on?sudo: aa-status: command not found$echo "is the mandatory access control layer on?"; getenforce; sestatus 2>/dev/null | head -3is the mandatory access control layer on?EnforcingSELinux status:                 enabledSELinuxfs mount:                /sys/fs/selinuxSELinux root directory:         /etc/selinux

   Expected resultAppArmor enabled on the Debian host; Enforcing from getenforce on the RPM one.

   Success conditionYou know which mechanism you are looking at before you try to change it.

Troubleshooting

• Time is spent on Kubernetes for Domain 4.

  Why: The domain is called 'Automation, Orchestration, and Scripting', which sounds like orchestrators.

  Fix:The pool names containers in 46 questions and Kubernetes in 4, and over half the domain is shell scripting. Spend the time on bash, git and podman.

• A container is expected to need root.

  Why: Rootless podman runs the container as root INSIDE while the invoking user is unprivileged outside.

  Fix:podman unshare cat /proc/self/uid_map shows the mapping - container uid 0 is your own uid on the host. Nothing in this domain needs a root shell.

• Only SELinux or only AppArmor is revised.

  Why: The Security domain is family-neutral and each family ships a different system - AppArmor on the Debian host, SELinux enforcing on the RPM one.

  Fix:Know SELinux properly, since the pool names it in 35 questions against AppArmor's 4 - but be able to check AppArmor's state and find its profiles.

Official sources

• CertGrid - CompTIA Linux+ practice
• CompTIA - Linux+ (XK0-006) exam objectives