easyMultiple Select
CAS-004 Is hardening a Linux server Practice Question
A security engineer is hardening a Linux server. Which TWO of the following are best practices for preventing privilege escalation attacks?
⚠ Common exam trap
CAS-005 often tests the misconception that 'removing SUID from all binaries' or 'disabling non-root accounts' is a hardening best practice, when in fact these break functionality and violate least-privilege principles.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Apply kernel hardening with sysctl
Option B is correct because applying kernel hardening with sysctl (e.g., setting kernel.kptr_restrict, kernel.dmesg_restrict, kernel.yama.ptrace_scope, and disabling unprivileged user namespaces) reduces the kernel attack surface and blocks common privilege-escalation vectors such as kernel pointer leaks and ptrace-based injection. Option C is correct because running SELinux in enforcing mode confines processes with mandatory access control (type enforcement, domain transitions), so even if an attacker exploits a service, the policy limits what the compromised domain can do and prevents escalation to unconfined root. Option A is wrong because disabling all non-root accounts is not a hardening practice; it breaks accountability and least privilege, and root-only access increases risk rather than preventing escalation. Option D is wrong because removing the SUID bit from all binaries indiscriminately breaks legitimate tools like sudo, passwd, and ping; SUID should be audited and minimized, not globally stripped. Option E is wrong because restricting cron to root alone does not prevent privilege escalation and can conflict with legitimate per-user or system maintenance jobs; cron should instead be permission-controlled and monitored.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable all user accounts except root
Why it's wrong here
Disabling all non-root accounts destroys accountability and forces shared root use, worsening escalation risk rather than reducing it. Least privilege means each administrator holds a distinct, auditable account. The stem asks for privilege-escalation prevention, which this configuration actively undermines.
- ✓
Apply kernel hardening with sysctl
Why this is correct
sysctl tunes kernel parameters at runtime, such as disabling IP forwarding or restricting dmesg and kptr access. These settings shrink the kernel attack surface that local users could exploit to gain elevated privileges, directly satisfying the hardening requirement.
- ✓
Enable SELinux in enforcing mode
Why this is correct
SELinux in enforcing mode applies mandatory access control, confining processes and users to defined policies even when running as root. This blocks privilege escalation via misconfigured binaries or exploited daemons, satisfying the requirement to prevent escalation rather than merely log it.
- ✗
Remove the SUID bit from all binaries
Why it's wrong here
Removing SUID from every binary breaks legitimate functions such as passwd and sudo, which require elevated execution. The targeted approach strips SUID only from binaries lacking a genuine need. Selective auditing is the correct practise; blanket removal is not.
- ✗
Restrict cron jobs to root only
Why it's wrong here
Restricting cron to root removes a non-root escalation path but leaves the wider attack surface untouched, and root-owned cron entries still execute attacker-controlled scripts if writable. It is tempting because cron is a known privilege-escalation vector, yet least privilege, patching and sudo auditing are the broader controls required.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every CAS-005 question from scratch — 973 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CAS-005 exam.