Course contentsShow
← Linux
Lesson 1056 of 1,8199. Security Hardening and Mandatory Access ControlFree lesson

Testing for Policy Bypass via Side Channels

Identify potential side-channel leakage through non-restricted system interfaces.

In this lesson, you will learn how to identify scenarios where attackers leverage non-restricted system interfaces to infer sensitive data or bypass Mandatory Access Control (MAC) policies.

The Concept of Side-Channel Leakage

Mandatory Access Control (MAC) systems like SELinux or AppArmor are excellent at restricting direct access to files, sockets, and memory. However, security policies often focus on "what you can touch" rather than "what you can observe." A side channel occurs when a restricted process gathers information about a forbidden resource by observing secondary effects—such as timing, power consumption, or shared system state—that are not explicitly protected by the policy.

Identifying Potential Leakage

When hardening a system, you must consider interfaces that appear harmless but reveal system behavior. A classic example is the /proc filesystem. Even if a process is denied read access to a sensitive file, it might still have permission to read system-wide statistics that change based on whether that sensitive file is being accessed by another process.

Consider a scenario where an unprivileged service attempts to determine if a restricted backup process is running:

# An attacker monitoring jitter on non-restricted interfaces
# Check /proc/uptime or /proc/loadavg to infer activity
while true; do
    cat /proc/loadavg >> state_log
    sleep 0.1
done

If the restricted backup process causes a measurable spike in loadavg or modifies hardware-level timing, an attacker can use this "side channel" to time their actions, effectively bypassing the security policy’s intent to keep the backup process's existence hidden.

Testing for Vulnerabilities

To test for these bypasses, perform a "differential analysis." Execute a restricted action (like reading a locked file) and simultaneously monitor non-restricted global interfaces:

  1. Timing Analysis: Does a "Permission Denied" error take longer to return than an "Access Granted" success? If so, the system is leaking information about the file's existence or the policy evaluation logic.
  2. Resource Exhaustion: Can you observe changes in global counters (like context switches in /proc/stat) that correlate with forbidden activities?

If you find that an unrestricted interface provides a signal that correlates with restricted data, you must tighten your MAC policy to restrict access to those telemetry files or interfaces.

Key Takeaway: A robust security policy must restrict not only direct access to sensitive data but also the secondary system interfaces that could leak information through timing, resource usage, or state changes.