📖 Report📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 91 · Tricks

Operating System Security — Exam Tricks

Four high-yield patterns and three practice scenarios: separating Active Directory from Group Policy when the exam blurs their roles, the DAC vs. MAC decision rule that never fails, why SELinux blocks attacks that Linux file permissions allow, and the least-privilege thread connecting all three technologies.

Trick 1 Active Directory vs. Group Policy — Identity vs. Configuration

The exam’s most frequent OS security trap is assigning the wrong function to AD vs. Group Policy. They are complementary but distinct. The separation is clean once you internalize one rule:

  • Active Directory = WHO — who the user is, what groups they belong to, whether their account exists, what their password is. AD is a database of identities and resources. It does not push settings to computers.
  • Group Policy = WHAT — what the computer or user can and cannot do. GP pushes settings (password rules, screen locks, USB blocks) to machines and users. It relies on AD as its delivery infrastructure but is a separate technology.

Common wrong answers to recognize and reject:

  • “Active Directory enforces password complexity on all workstations” — Wrong. Password complexity is a Group Policy setting, not an AD user attribute.
  • “Group Policy stores user accounts and handles authentication” — Wrong. Authentication is AD’s function.
  • “Group Policy can function as a standalone without Active Directory” — Partially wrong. Local Group Policy exists on every Windows machine but has no central management. Domain-scale Group Policy requires AD.

Help desk tasks (password resets, account unlocks, group membership changes) = Active Directory.
Security configuration deployment (screen lock, USB disable, login scripts) = Group Policy.

Rule: AD = identity database (WHO). Group Policy = configuration delivery (WHAT). Group Policy depends on AD; AD does not depend on Group Policy. Help desk uses AD. Security hardening uses Group Policy.
Trick 2 DAC vs. MAC — Owner Control vs. Central Policy

DAC and MAC are tested as a concept pair on the exam. The distinguishing question is always: who has the authority to set permissions?

  • DAC — the owner decides. In standard Linux, the user who creates a file controls who can access it. The system enforces those choices, but the choice itself belongs to the owner. This is “discretionary” because it is at the owner’s discretion.
  • MAC — the policy decides. An administrator defines security rules at the system level. No user — not even the resource owner — can grant permissions that the policy prohibits. This is “mandatory” because the policy is mandatory and cannot be circumvented.

The exam trigger phrases:

  • “Users cannot override security policies regardless of file ownership” → MAC
  • “Resource owners determine who can access their files” → DAC
  • “Centrally enforced, cannot be changed by users” → MAC
  • “Default Linux access control model” → DAC
  • “SELinux” → always MAC

Memory hook: Discretionary = your own discretion (the owner chooses). Mandatory = you have no choice (the policy mandates it).

Rule: DAC = owner’s discretion. MAC = administrator’s mandate. “User cannot override” or “centrally enforced” = MAC. “Owner controls permissions” = DAC. SELinux always = MAC.
Trick 3 SELinux Blocks What Linux Permissions Allow — Both Checks Must Pass

The exam scenario that catches candidates off guard: Linux file permissions (DAC) would allow an access, but the access is still denied. Candidates reach for iptables, sudo, or AppArmor. The answer is SELinux.

How SELinux interacts with Linux DAC permissions:

  • Linux checks DAC file permissions first. If DAC denies, the access is blocked — SELinux is not consulted.
  • If DAC permits, SELinux policy is checked second. If SELinux denies, the access is blocked regardless of what DAC said.
  • Both must allow. DAC alone permitting is not sufficient.

Application confinement in practice: The web server process runs as user apache. In DAC, apache might have read access to its home directory and several configuration files. In SELinux, the httpd_t process label is only allowed to access specific resource labels — web content, web ports, web logs. Even if apache has DAC read access to /etc/shadow, the SELinux policy for httpd_t does not include the shadow_t label — access denied.

Exam scenario: “The file permissions would have allowed the access, but it was denied.” → SELinux enforced MAC policy after DAC check passed.

Rule: SELinux = second check after DAC. Both must allow. If DAC allows but SELinux denies, access is blocked. The scenario “permissions allowed it but the access was still denied” = SELinux.
Trick 4 Least Privilege Appears in All Three Technologies — Know Which Layer Enforces It

The principle of least privilege runs through the entire chapter, implemented differently at each layer. The exam tests whether candidates can identify which technology is the right tool for least-privilege enforcement in a given context:

  • Active Directory — identity-layer least privilege: Users get access only to the groups (and therefore resources) their role requires. Access is provisioned by group membership, not broad individual grants. Offboarding removes group memberships, immediately revoking access.
  • Group Policy — workstation-layer least privilege: Standard users cannot install software, access system tools, or change security settings. Admin rights are removed from end-user accounts. Users can only do what the policy explicitly permits on their workstation.
  • SELinux — kernel-layer least privilege: Processes are confined to exactly the kernel resources their security label permits. No runtime override is possible. Least privilege is enforced even against root-level exploits because SELinux policy can restrict what even root can do within a process context.

The exam question pattern: “Which technology enforces least privilege at the operating system kernel level?” → SELinux. “Which technology prevents users from installing unauthorized software on Windows workstations?” → Group Policy. “Which technology limits user access to only the network resources their role requires?” → Active Directory (group-based access control).

Rule: Kernel-level process confinement = SELinux. Workstation behavior restrictions = Group Policy. Resource access scoped to role = Active Directory. All three implement least privilege at different layers.
Practice Scenarios
Scenario A: A new employee joins the Accounts Payable department. On day one, they need access to the finance file share, the accounting application, and the shared finance printer. On day three, a security audit finds the employee also has read access to the HR records share and the IT infrastructure documentation share, because a previous administrator assigned permissions directly to the user account rather than through groups. The IT manager wants to fix both issues and implement a process that prevents this from recurring. What is the correct architecture, and what Active Directory feature solves both the current and future problem?
Answer: The correct architecture is group-based access control. Each resource (finance file share, accounting application, finance printer, HR records, IT documentation) should have its own security group. Access to the resource is granted to the group, not to individual users. When a new employee is onboarded, they are added to the groups appropriate for their role — in this case, the Finance group, not the HR or IT groups. The fix for the current employee: remove the direct user permission assignments from the HR records and IT documentation shares. Add the employee to the Finance-Access group, which grants the finance file share, accounting application, and printer. The HR and IT resources should only be accessible through their respective groups, which this employee is not a member of. The process that prevents recurrence: require that all resource access is granted exclusively through security groups in Active Directory, never through direct user permission assignments. When a new employee joins, provisioning consists entirely of adding them to the correct AD security groups for their role. This creates a single point of management: to audit access, review group memberships; to offboard, remove group memberships and all access is revoked simultaneously across all resources.
Scenario B: A security administrator needs to deploy the following settings to all 1,200 Windows workstations in the organization: (1) passwords must be at least 16 characters with complexity; (2) workstations must lock after 3 minutes of inactivity; (3) USB mass storage devices must be blocked; (4) Command Prompt and PowerShell must be blocked for standard users; (5) all workstations must automatically install a specific security monitoring agent at startup. What is the most efficient approach, and why would configuring each workstation individually be unacceptable?
Answer: The correct approach is Group Policy. Create a Group Policy Object (GPO) in the Group Policy Management Editor with all five settings configured: the password complexity policy under Computer Configuration ’ Windows Settings ’ Security Settings ’ Account Policies; the screen lock timeout under Computer Configuration ’ Administrative Templates; the USB storage block via device installation restrictions; the Command Prompt and PowerShell restrictions under User Configuration ’ Administrative Templates ’ System; and the software installation of the monitoring agent via Computer Configuration ’ Software Settings. Link the GPO to the domain or the relevant OU. Once linked, all 1,200 domain-joined workstations automatically receive and enforce the policy at the next Group Policy refresh (every 90 minutes by default for computers, or immediately via gpupdate /force). No per-machine action is required. If any of the five settings needs to change in the future, updating the single GPO propagates the change to all 1,200 machines automatically. Configuring each machine individually is unacceptable for three reasons: it does not scale (1,200 machines x 5 settings = 6,000 manual operations); settings drift over time as machines are rebuilt or reset; and there is no enforcement mechanism — a user or local admin could revert settings on any individual machine. Group Policy re-enforces settings at every refresh, overriding any local changes that conflict with domain policy.
Scenario C: A Linux web server is running Apache with SELinux enforcing mode enabled. An attacker successfully exploits a remote code execution vulnerability in a web application running on the server. The attacker tries four post-exploitation actions: (1) read /etc/shadow to obtain password hashes; (2) write a backdoor executable to /usr/bin; (3) read the web application’s configuration file containing database credentials in /var/www/html/config.php; (4) open an outbound reverse shell connection on port 4444. Which actions succeed, which fail, and why?
Answer: Action 3 succeeds. The web application configuration file (/var/www/html/config.php) is in the web content directory, which carries the httpd_sys_content_t label. The Apache process context (httpd_t) is explicitly permitted by SELinux policy to read files with this label — that is its designed function. The attacker, running within the httpd_t context, has the same access. Actions 1, 2, and 4 fail due to SELinux MAC enforcement, despite potentially having DAC permission to attempt them: Action 1 fails: /etc/shadow carries the shadow_t label. The httpd_t process context is not permitted to read shadow_t files. SELinux denies the read even if the web server’s Linux user account had file-system-level read access. Action 2 fails: /usr/bin contains executables with the bin_t label. The httpd_t context is not permitted to write to bin_t files. The backdoor cannot be written to a system binary directory. Action 4 fails: SELinux network port policy for httpd_t only permits the process to listen on or connect to ports defined as web ports (80, 443, and a few others). Outbound connections to port 4444 are not in the httpd_t network policy — SELinux blocks the socket call. This scenario illustrates SELinux application confinement working as designed. The attacker fully controls the Apache process but is confined within its security context. They can read what Apache was supposed to read, but cannot escape that context to access the password file, modify system binaries, or establish arbitrary network connections.