Designing for Fail-Closed Security

In this lesson, you will learn how to design access control systems that default to a "denied" state if a security policy engine crashes or encounters an error.

The Principle of Fail-Closed Design

When designing security systems, we must consider what happens when a component fails. A fail-open system defaults to allowing access if the security logic cannot be processed, which is a massive risk. Conversely, a fail-closed system treats any internal error or system crash as a signal to block all traffic or access requests until the policy engine is safely restored.

In Linux, this is a fundamental requirement for high-security environments like Mandatory Access Control (MAC) systems (e.g., SELinux or AppArmor).

Implementing Fail-Closed Logic

Imagine you are writing a custom helper script or a system service that checks if a user is allowed to perform a sensitive operation based on an external policy file. If your script hits a bug—perhaps the policy file is corrupted or the database is unreachable—the logic must not default to allow.

Here is a simplified conceptual approach:

# Check access policy
if check_policy "$USER" "$ACTION"; then
    # Access is explicitly granted
    execute_action
elif [ $? -ne 0 ]; then
    # Policy engine encountered an error (e.g., database down)
    # Fail-closed: Deny by default
    log_security_alert "Policy engine failure: Access denied to prevent risk."
    exit 1
else
    # Policy explicitly denies
    exit 1
fi

By ensuring that the else block (or a failure state) results in an exit 1 (denial), you guarantee that the system does not "accidentally" allow an action just because the security check failed to complete.

When applying this to kernel-level security or systemd services, ensure that your configuration enforces strict policies. If a service requiring a specific security profile fails to load the profile correctly, the service itself should remain in a halted or "failed" state rather than dropping to a permissive default. Always assume that if the "gatekeeper" (your policy engine) goes offline, the "gate" must remain locked.

Key Takeaway: A security system must be designed so that any failure in the evaluation logic defaults to a restricted state, ensuring that silence or error does not translate into unauthorized access.