Manage security practice questions

passwd -l apache

Why wrong: Locks password but doesn't prevent SSH key login.

chage -l apache

Why wrong: Lists password expiry; does not restrict login.

usermod -e 1 apache

Why wrong: Setting the account expiration date to 1 (early epoch) immediately expires the account, which does prevent login immediately. However, this is not the preferred method because it disables all logins (including non-interactive) and is not the standard way to disable interactive logins for a service account. The recommended approach is to change the shell to /sbin/nologin.

SELinux is in enforcing mode and the policy is misconfigured.

Why wrong: Running getenforce and seeing 'enforcing' only confirms SELinux is active, not that it is the cause of a denial. If SELinux policy were truly misconfigured and blocking access, switching the system into permissive mode with setenforce 0 would stop all SELinux enforcement and the application would no longer be denied. Since the problem persists in permissive mode (as implied by the correct answer), a misconfigured policy cannot be responsible, because permissive mode logs but does not deny SELinux faults.

The application's SELinux context is incorrect and needs relabeling.

Why wrong: A wrong SELinux context (type or label) would still only produce denials while SELinux is in enforcing mode. In permissive mode, SELinux does not enforce type enforcement and will allow access even if the application or target is mislabeled; it merely records an AVC denial in the audit log. Therefore, an incorrect context cannot explain a failure that survives setenforce 0, and relabeling would not remove a denial caused by ordinary file permissions or ACLs.

The change requires a reboot to take effect.

Why wrong: setenforce 0 is an immediate runtime switch; it changes the current SELinux mode without requiring a reboot, so no reboot is needed for the test. A reboot would only be necessary to load a new SELinux state after editing /etc/selinux/config, or to re-enable SELinux after a 'disabled' mode, but that has nothing to do with a denial that persists in permissive mode. Since permissive mode already takes effect instantly, any remaining failure cannot be attributed to a pending reboot.

jdoe client1.example.com=(root) ALL

Why wrong: This rule is incorrectly missing the NOPASSWD tag. While the host and runas restrictions are exactly as required, without NOPASSWD sudo will invoke a password prompt, and jdoe would have to authenticate before the command runs. That conflicts with the stated requirement that the command be executed without prompting for a password.

jdoe ALL=(root) NOPASSWD: ALL

Why wrong: This rule sets the host list to ALL instead of client1.example.com. As a result, jdoe could use this sudo privilege from any managed host, which over-expands the intended scope and violates the requirement to restrict the rule to client1. Having NOPASSWD does not compensate for the incorrect host wildcard.

jdoe ALL=(root) ALL

Why wrong: This rule has two separate failures: the host list is ALL, making the privilege available from every host, and the NOPASSWD tag is absent, so a password prompt will occur. Neither component matches the requirement of a passwordless rule limited only to client1.example.com for user jdoe.

chcon -l

Why wrong: The `chcon -l` option is incorrect because `chcon` is used to *change* the SELinux context of a file, not to display it. Even though `-l` allows specifying a context label, the command does not print the current or resulting context; it modifies the inode's security attributes.

id -Z

Why wrong: The `id -Z` option is incorrect because it prints the SELinux security context of the *current process* (or the user's initial context), not the contexts of arbitrary files. It answers "what context am I running in?" rather than "what is this file's context?".

getenforce

Why wrong: The `getenforce` option is incorrect because it only reports the *global* SELinux enforcing mode (Enforcing, Permissive, or Disabled), not the security context of any particular file. It is a system-status query, not a per-object context display.

The /etc/nologin file exists.

Why wrong: The mere existence of /etc/nologin blocks local console and terminal logins by displaying its contents to non-root users, but sshd does not consult this file. SSH access is governed by the SSH daemon's own configuration and PAM stack; unless pam_nologin is explicitly enabled for the sshd service, the file has no effect on incoming SSH connections. Therefore, /etc/nologin is irrelevant to whether a user can SSH.

The user has sudo privileges.

Why wrong: Having sudo privileges grants the user the ability to execute commands as another user (typically root) after logging in, but it is not an authentication mechanism for SSH. The SSH server validates credentials against account passwords or SSH keys; sudoers membership is never queried during the SSH handshake. Consequently, a user with sudo can still be unable to SSH if their account is locked or their shell is invalid, and an average user without sudo can SSH normally provided other conditions hold.

chcon -u system_u /home/user/www/index.html

Why wrong: Changing the SELinux user (the -u parameter) to system_u on index.html does not affect the type attribute, which is what httpd_t (the Apache domain) actually checks for read access. Even with system_u as the user, the file still retains a type like user_home_t that is not in the allowed set for httpd_t, so denial persists. Furthermore, chcon makes a transient change that does not survive a filesystem relabel, unlike a proper semanage fcontext rule.

semanage fcontext -a -t httpd_sys_content_t '/home/user/www(/.*)?' && restorecon -Rv /home/user/www

Why wrong: This is the correct approach because semanage fcontext establishes a persistent, regex-based rule that maps /home/user/www and all files below it to the httpd_sys_content_t type, and restorecon -Rv applies that type immediately. Once the type is httpd_sys_content_t, the httpd_t domain has explicit read permissions via SELinux policy, allowing Apache to serve the page. The rule survives future relabels, making it a durable fix, and the regex (/.*)? ensures all nested content, not just the current index.html, is correctly labeled.

chcon -r object_r /home/user/www/index.html

Why wrong: The lowercase -r in chcon is for setting the SELinux role, not for recursion (that would be -R). Changing the role to object_r has no effect on Apache's ability to read the file because SELinux type enforcement, not role, governs whether httpd_t can access a file. Additionally, chcon is a manual change that is not persisted in the file context policy; if the filesystem is relabeled, the original type returns, leaving the problem unresolved.

Add 'alice web1.example.com=(root) NOPASSWD: ALL' to /etc/sudoers.d/alice.

Why wrong: The rule grants alice passwordless sudo rights to execute any command as root on the host web1.example.com. While NOPASSWD removes the password prompt, the command specification ALL is far broader than the single restart needed. This violates least privilege: alice could run useradd, visudo, or other administrative commands.

Add 'alice web1.example.com=(root) /usr/bin/systemctl restart httpd' to /etc/sudoers.d/alice.

Why wrong: This rule limits alice to the appropriate systemctl restart httpd command, but without the NOPASSWD tag she will be prompted for her password. If the goal is passwordless restart—as implied by the requirement—the absence of NOPASSWD makes the rule functionally insufficient. Also note that sudo will still require a valid password and tty, potentially blocking automation.

Change '%wheel ALL=(ALL) ALL' to '%wheel ALL=(ALL) NOPASSWD: ALL' in /etc/sudoers.

Why wrong: Modifying the wheel group line affects every user in the wheel group, not just alice, and grants them all passwordless root access. This is a system-wide change that drastically increases the attack surface and violates the principle of least privilege. The original line already grants full root; adding NOPASSWD only removes the password check without addressing command scoping.

firewall-cmd --runtime-to-permanent

Why wrong: The firewall-cmd --runtime-to-permanent command persists the current runtime configuration to the permanent configuration files, but it does not itself add any services or rules. If the required HTTPS allow or SSH drop rules were never added to the runtime configuration, this command simply saves an incomplete firewall state. Therefore, it fails to fulfill the requirement to add the necessary firewall rules; it only copies whatever rules are already active.

firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh reject' --permanent

Why wrong: Using the reject action in a rich rule causes firewalld to send an ICMP unreachable packet or TCP RST back to 192.168.1.100, explicitly indicating the port is closed. This differs from the desired silent drop, which discards packets without any response, making the host appear nonexistent. A reject action is also more detectable during port scans and does not meet a requirement to hide or block access without feedback.

firewall-cmd --add-service=http --permanent

Why wrong: This command adds the http service, which opens TCP port 80 for unencrypted web traffic, not port 443 for HTTPS. If the web server must accept secure connections, this rule leaves HTTPS blocked and would cause the initial secure connection attempt to fail. Because the requirement specifically calls for HTTPS, adding http is the wrong service even though the syntax and persistence behavior are valid.

Set the SELinux boolean httpd_enable_homedirs to on using setsebool.

Why wrong: The boolean httpd_enable_homedirs is specifically designed to control whether Apache can access user home directories (e.g., public_html via mod_userdir). It has no bearing on the labeling or access rights for a custom directory under /var/www. Even if enabled, it would not grant httpd write access to /var/www/customcontent; that requires a proper file context with an httpd_writable type. Thus, toggling this boolean is irrelevant to the stated requirement.

Change the context to httpd_sys_content_t using chcon -R -t httpd_sys_content_t /var/www/customcontent

Why wrong: chcon changes the SELinux context immediately, but the change is temporary and will be reverted by any subsequent restorecon or filesystem relabel. Additionally, httpd_sys_content_t is read-only for the web server; it permits Apache to read and serve static content but not to write or modify files. Since the requirement is to allow httpd to write, using this type would deny write operations. A persistent semanage fcontext rule with httpd_sys_rw_content_t is needed.

Run semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/customcontent(/.*)?' without running restorecon.

Why wrong: semanage fcontext only adds a rule to the SELinux policy database that defines the default context for a path; it does not modify the current context of any existing files. Without running restorecon, the actual files in /var/www/customcontent retain their original context (likely default_t or unlabeled), which Apache cannot access or write to. The rule only takes effect when restorecon is executed or when new files are created in the directory. Therefore, omitting restorecon leaves the directory incorrectly labeled, so this option is incomplete.

1. Reload firewall: firewall-cmd --reload 2. Add HTTP service: firewall-cmd --permanent --add-service=http 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services

Why wrong: Executing --reload before adding the services is ineffective because the reload only reads the current permanent configuration, which at that point contains no http or https rules. The two --permanent --add-service commands then update the on-disk configuration, but because no second reload is performed, the runtime firewall never receives those changes. Consequently, --list-services at the end would not display http or https, leaving web access blocked.

1. Add HTTP service: firewall-cmd --add-service=http (without --permanent) 2. Add HTTPS service: firewall-cmd --add-service=https (without --permanent) 3. Reload firewall: firewall-cmd --reload 4. Verify: firewall-cmd --list-services

Why wrong: Omitting --permanent applies the services only to the live runtime set, not to the persistent configuration files. When --reload is then executed, firewalld rebuilds the runtime rules from the permanent configuration on disk, discarding all runtime-only additions. As a result, these http and https rules survive only until the reload, so they would be lost immediately, and verification after the reload would show neither service.

1. Add HTTP service: firewall-cmd --permanent --add-service=http 2. Reload firewall: firewall-cmd --reload 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services

Why wrong: This sequence adds HTTP permanently, reloads to activate it, and only then adds HTTPS permanently without a subsequent reload. Although HTTPS is now stored in the persistent configuration, the running firewall has not been refreshed after that second permanent change, so the HTTPS rule is not present in the current runtime. The final --list-services would show http but not https, leaving the webserver incomplete and inaccessible via HTTPS until another reload is performed.

IP address: A 32-bit number used to divide an IP address into network and host portions.

Why wrong: This definition is incorrect because a 32-bit number used to divide an IP address into network and host portions is called a subnet mask, not an IP address. An IP address is the actual numeric label assigned to an interface, while the subnet mask is a separate value that helps interpret that address. Someone selecting this option would confuse the address itself with the network mask that accompanies it.

Default gateway: A server that resolves domain names to IP addresses.

Why wrong: This definition is incorrect because resolving domain names to IP addresses is the function of a DNS server, not a default gateway. A default gateway is a layer-3 router interface that forwards packets from one IP subnet to another; it has no role in name resolution. The wrong phrasing conflates application-layer name translation with network-layer packet routing.

alice localhost=(ALL) ALL

Why wrong: This line uses localhost as the Host_List, but sudo compares that list against the system's canonical hostname; on a typical machine the value is not literally localhost, so the rule will not apply. Additionally, (ALL) as the runas specification allows executing commands as any target user, not just root, making the entry both syntactically unreliable and overly broad.

alice ALL=(ALL) ALL

Why wrong: Incorrect. While 'alice ALL=(ALL) ALL' is a valid entry for full sudo privileges, it allows running commands as any user, not just root. The question specifically requires running commands as root, making this less precise.

%alice ALL=(ALL) ALL

Why wrong: This line is wrong for two distinct reasons. The leading percent sign makes alice a group name, not a user; sudoers requires a bare username for user entries. Even if the group alice exists, (ALL) in the runas position grants the group the ability to run commands as any user, which exceeds the required root-only scope.

027

Why wrong: A umask of 027 applies a mask of 0 for owner, 2 for group, and 7 for others to the base permissions of 666 for new files, yielding 640. That grants the owner read/write and the group read, but removes all permissions from others, so files are no longer readable by everyone. Since the requirement is that new files be readable by all, 027 fails because it denies others read access.

002

Why wrong: A umask of 002 only masks the write bit for others (2), so files retain 664, which includes group write permission. The group is given write access, not just read, which is beyond the stated requirement and could allow unintended modifications. While others can still read, the group's extra write permission makes this umask unsuitable for a simple 'readable by all' goal.

077

Why wrong: Setting umask 077 masks all group and others permissions (7 = read+write+execute) from the base 666, leaving only 600. That gives the owner full read/write but provides no access to either the group or others, so the file is completely unreadable to anyone else. This is a restrictive umask designed for privacy, not for making files readable by all.

SELinux is blocking SSH from reading the key.

Why wrong: SELinux in its default targeted policy allows the sshd process to read a user's ~/.ssh/authorized_keys file, provided the context is the standard `user_home_t`/`ssh_home_t` type; a context problem would produce AVC denials and typically break more than key auth. Because password authentication succeeds, sshd can already access the home directory and run normally, and key authentication-specific failure points are file/directory permissions rather than SELinux. Reset the context with `restorecon -R -v ~/.ssh` only if audit logs confirm denials, otherwise it is a red herring.

The public key is not in ~/.ssh/authorized_keys.

Why wrong: If the public key truly were absent from authorized_keys, sshd would fail with a generic 'Permission denied (publickey)' without even evaluating key-based login, but in this scenario password auth works and the key was likely added by the user. The actual reason is that sshd's StrictModes checks the permissions of ~/.ssh and authorized_keys before trusting them, and a 755 directory causes sshd to refuse to use any key files inside it, regardless of whether the key exists. Verifying the key is present may look fine, yet authentication still fails because the overly permissive directory short-circuits the login.

SSH is configured to use a different port.

Why wrong: Changing the port that sshd listens on—whether in /etc/ssh/sshd_config (Port directive) or per-connection with `-p`—only affects the network socket and has no effect on the server's authentication logic. Public-key authentication is handled by the same sshd process and the same authorized_keys lookup regardless of which port the client connects to. If a non-standard port were the cause, the client would receive a connection refused/timeout rather than an authentication failure, so this option cannot explain a key-authentication problem.

/etc/security/passwd

Why wrong: This path is not a standard file in Red Hat Enterprise Linux. The /etc/security/ directory contains PAM module configuration files, not a user password database; creating or relying on /etc/security/passwd would not affect system authentication. Since local user hashes are instead stored in /etc/shadow, this option is incorrect.

/etc/passwd

Why wrong: While /etc/passwd defines local user accounts, its password field on modern systems simply contains an 'x' as a placeholder, meaning the actual hash has been shadowed to /etc/shadow. Because /etc/passwd is world-readable, storing hashes there would expose them to offline cracking attempts. Thus, this file does not contain the hashed passwords themselves.

/etc/gshadow

Why wrong: The /etc/gshadow file is the shadow equivalent for group passwords and group administrator (admin) membership, not for individual user passwords. It stores an encrypted hash for a group's password if one is set, plus the list of group admins, and is also readable only by root. User authentication hashes belong in /etc/shadow, making this option incorrect.

dev ALL=(root) PASSWD: /usr/local/bin/deploy.sh

Why wrong: This sudoers rule requires dev to authenticate with their own password before running /usr/local/bin/deploy.sh as root. Because the stated requirement is a passwordless invocation, PASSWD (or the implicit default of requiring a password) does not satisfy it. The command path and runas user are correctly constrained, but the authentication tag is incorrect.

dev ALL=(ALL) NOPASSWD: /usr/local/bin/deploy.sh

Why wrong: Although this rule includes NOPASSWD and a fully qualified command, the runas list (ALL) allows dev to execute the script as any system user, not just root. This overprovisions the account, as the requirement solely calls for root execution, and could permit unintended privilege escalation or access as other users. A restrictive sudoers entry should name only the necessary target user, here root.

%dev ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh

Why wrong: Using the % prefix designates a user group, not the individual user 'dev'. If a group named dev exists, every member of that group would receive passwordless sudo rights to the command, which is broader and different from the intended single-user grant. Without the %, dev is interpreted as a username, so this entry fails to confer the requested privilege to the correct principal.

The NOPASSWD option eliminates the need for a password.

Why wrong: The NOPASSWD option removes the password prompt for the sudo rule, but it is not the core security flaw. If the rule required a password, jane would simply type her own password (which she knows) and then still be able to use less's ! command to spawn a root shell. The real risk is that the whitelisted command itself has an escape vector, not the absence of a password challenge.

The entry uses (ALL) instead of (root), allowing jane to run as any user.

Why wrong: Changing (ALL) to (root) would restrict which user jane can run less as, but it would not stop the escalation. When less is invoked as root, its ! command spawns a shell with root privileges regardless of whether the sudoers entry specifies (root) or (ALL). The runas user broadens the impact, but even a root-only rule allows jane to obtain a root shell because less executes commands under its own (root) privilege context.

The command /usr/bin/less can be used to read any file.

Why wrong: The ability to read any file is a capability of the less command itself, and it is not by itself a privilege escalation. If jane were meant to audit logs or inspect system files, reading via less could be a legitimate task. The critical issue is that less does not merely read; it can execute arbitrary commands via its ! feature, which elevates her from a file reader to a root shell holder, making the command choice the primary concern.

The script is in the wrong directory.

Why wrong: The directory /var/www/cgi-bin is the standard CGI directory on Red Hat Enterprise Linux, configured via ScriptAlias /cgi-bin/ /var/www/cgi-bin/ in the Apache configuration. A CGI script placed there is correctly located, and a wrong-path problem would normally produce a 404 Not Found error, not a 500 Internal Server Error. Therefore, the directory is not the cause of the reported failure.

The script is not marked as executable.

Why wrong: Although a CGI script must be executable, simply setting the executable bit does not address the SELinux denial causing this failure. The error log may show 'Permission denied' for both ordinary mode restrictions and SELinux denials, but the executable bit alone cannot override a missing httpd_sys_script_exec_t type. If the problem were only a missing executable mode, `chmod +x` would fix it immediately; the given scenario points directly to a context issue, so this option is not the root cause.

The file permissions are incorrect.

Why wrong: Incorrect file permissions could mean wrong ownership or mode bits, but no such problem is indicated in the exhibit; the script is in the standard directory and is likely owned properly. Even if the apache user lacked read or execute access, a RHEL 500 error from a CGI script is typically accompanied by an AVC denial in /var/log/audit/audit.log that cites the missing SELinux type. Fixing permissions alone would not re-contextualize the file, so SELinux corrections are still required, making this option an incorrect explanation of the actual error.

firewall-cmd --add-service=http --zone=internal; firewall-cmd --reload

Why wrong: Adding the service without --permanent creates a runtime-only rule that disappears the moment firewalld reloads or restarts. The subsequent --reload actually erases your change, leaving the internal zone without http access. To persist across reboots and activate the rule cleanly, the permanent configuration must be modified explicitly, not assumed by the runtime command.

firewall-cmd --permanent --add-service=http --zone=internal; systemctl restart firewalld

Why wrong: Using --permanent alone writes the rule to disk, but systemctl restart firewalld is overly disruptive and unnecessary for this scenario. Restarting tears down all firewall rules, active connections, and can interrupt existing traffic, whereas firewalld supports a lightweight reload that applies configuration changes atomically. The Red Hat recommended practice is to use firewall-cmd --reload, which re-reads the permanent config and activates the new service rule without dropping established connections.

firewall-cmd --zone=internal --add-service=http; firewall-cmd --runtime-to-permanent

Why wrong: The runtime command adds http to the active zone, and --runtime-to-permanent saves the entire current runtime state, including any other temporary modifications made earlier. This approach is imprecise and can inadvertently persist unintended runtime-only rules that were never meant to be permanent. The standard and safer method is to use --permanent directly on the add-service command, which targets exactly that rule for persistence and avoids capturing unrelated transient state.

Contains the user's UID.

Why wrong: User IDs (UIDs) are assigned and recorded in /etc/passwd as its third colon-separated field, not in /etc/shadow. The /etc/shadow file's fields start with the login name and then proceed directly to the password hash and aging parameters such as last change date and maximum days. While the shadow file does reference the matching passwd entry by username, it never stores the numeric UID itself, making this statement factually incorrect.

Is used to store encrypted group passwords.

Why wrong: Group password hashes, when they exist, are stored in /etc/gshadow rather than /etc/shadow. The /etc/shadow file exclusively handles local user account password data, whereas group-level security credentials and administrative information for groups are placed in the corresponding gshadow file. Encrypting group passwords is a separate feature that relies on a completely different file with its own permissions, so this option misattributes a function designed for group management.

Is readable by all users.

Why wrong: To protect password hashes from offline cracking attempts, /etc/shadow is not accessible to ordinary users; typical permissions are 0000 or 0640 owned by root:shadow. Only the root user and processes running with the shadow group (such as certain password management tools) can read it. In contrast, /etc/passwd is intentionally world-readable so that every process can look up UIDs and usernames without exposing the secret hashes that reside in the shadow file.