Suppose a machine runs a payment service, a log collector, and an image-processing worker.

All three processes need the CPU, memory, files, and network. They should not, however, have identical authority. The payment service may need a database credential. The log collector may need to read log files. The image worker may need access only to uploaded images and a temporary directory.

The operating system must let these programs share the machine while controlling what each one can do. That is a problem of protection.

Now suppose the payment service has a bug that returns another customer's records, an attacker steals an administrator's credentials, or a malicious request causes the service to stop responding. Preventing, detecting, and containing those outcomes is the broader problem of security.

The terms are closely related, but they are not interchangeable:

Protection controls how subjects may use objects inside a system. Security is the broader goal of preserving the system and its data in the presence of mistakes, misuse, and attacks.

Understanding this distinction makes it easier to reason about what an operating system can enforce, what depends on policy, and what must be handled by applications or other parts of the system.

Operating systems manage objects that should not be available to every program without restriction. These objects include process memory, files, devices, communication endpoints, and kernel-managed state.

A subject is an active entity attempting an operation. In an operating system, the subject is commonly a process or thread acting with a particular security identity.

An object is a resource on which an operation may be performed. A regular file, a memory region, another process, or a device can all be protected objects.

The operation describes the requested kind of access: read, write, execute, signal, create, delete, or some other object-specific action.

Every protection decision can therefore be framed as one question:

For example:

Protection is not simply the act of denying access. A system on which no program can access anything would be unusable. The real purpose is controlled sharing: allow the intended operations while preventing unintended ones.

A subject never reaches an object directly. Every request is mediated, which is what makes the check impossible to bypass rather than merely inadvisable to skip.

The decision can depend on more than the names of the subject and object. The requested operation matters as well. A process might be allowed to read a configuration file but not modify it, or append to a log without being allowed to erase its existing contents.

Protection also improves reliability. A faulty image worker that follows a wild pointer should not overwrite the payment service's memory, even if the bug is accidental rather than malicious. The same boundary that frustrates an attacker can contain an ordinary programming error.

Security asks whether important properties continue to hold despite hostile actions, mistakes, and failures.

Three foundational security goals are confidentiality, integrity, and availability.

Confidentiality means information is not disclosed to entities that are not authorized to receive it. Preventing the image worker from reading database credentials protects confidentiality.

Integrity means data and system state are not changed in unauthorized ways. Preventing the log collector from modifying the payment executable protects integrity.

Availability means authorized users and programs can obtain the service or resource when they need it. Preventing one workload from making the entire machine unusable supports availability.

These goals apply to a whole system, not just to individual kernel access checks. Security can depend on the operating system, application code, system configuration, authentication infrastructure, network design, operational practices, and physical control of the machine.

Consider a customer-record file whose operating-system protection permits only the backend service to read it. The protection rule may be working perfectly. The system can still lose confidentiality if the service has an application bug that sends any customer's record to any logged-in user. From the kernel's perspective, the authorized service read an allowed file and wrote bytes to an allowed network connection.

The kernel understands operations such as “read this file” and “send these bytes.” It usually does not understand an application's business rule such as “a customer may view only orders belonging to that customer.”

Protection is therefore one foundation of security, not a complete security solution.

Protection usually asks questions within a defined system:

Security asks a wider set of questions:

For the payment service, a protection question is whether the image worker can open the credential file. A security question is whether an attacker who compromises any exposed component can obtain or misuse payment data.

This difference in scope explains why a system can be well protected in one respect but insecure overall. It also explains why security work often uses operating-system protection mechanisms without ending at the operating-system boundary.

A protection policy states which accesses should be allowed. A protection mechanism implements and enforces those decisions.

Suppose the intended policy is:

The operating system needs mechanisms that can associate the service with a trustworthy identity, associate protection information with the file, check attempts to open it, and reject disallowed requests.

Keeping policy and mechanism conceptually separate is important. A mechanism can work exactly as designed while enforcing a bad policy.

Imagine that a credential file has been configured so that every local process may read it. When the image worker opens the file, the kernel checks the policy and permits the read. There was no enforcement malfunction; the configured policy granted too much access.

The reverse problem is also possible. The policy may be correct, but a flaw in its enforcement could let a process bypass the check. In that case, the mechanism has failed.

This gives two distinct questions when investigating an access-related incident:

That distinction prevents vague conclusions such as “permissions failed” when the real problem was an overly broad rule, or “the configuration was wrong” when the kernel did not enforce it correctly.

Separation also allows the same general mechanism to support different environments. A laptop, build server, and production database host can enforce different policies even if they use the same operating-system primitives.

An untrusted program cannot be responsible for enforcing restrictions on itself. If the only access check exists in application code, a modified or compromised application may skip it.

The operating system can enforce protection because it controls the boundary around privileged operations. A process cannot normally map another process's memory, read raw storage behind the kernel's back, or issue every device instruction directly. It must request protected operations from the kernel.

For a protection decision to be dependable, the system needs three properties.

First, the identity and relevant state used for the decision must not be freely forgeable by the requesting subject. A process must not be able to gain authority merely by claiming to be another process or user.

Second, the policy and enforcement code must be protected from the subject they constrain. If a process can rewrite the kernel's decision data, the check has little value.

Third, protected operations must pass through the enforcement point. A carefully implemented file-opening check is irrelevant if the same process can bypass the file interface and read arbitrary storage directly.

A conceptual component that makes these decisions is called a reference monitor. The ideal reference monitor:

Real operating systems are much larger and more complex than this idealized component. The model is still useful: missing checks, mutable enforcement state, and bypass paths each undermine protection in a different way.

The hardware and kernel cooperate to create this enforcement boundary. Processor privilege, controlled transitions into the kernel, and restricted memory access allow kernel checks to have authority over ordinary applications. If an attacker gains control of code inside the trusted boundary, many assumptions behind those checks no longer hold.

The trusted computing base, or TCB, is the collection of hardware, software, and configuration whose correct behavior is necessary for the system's security policy to hold.

The kernel is part of the TCB because it enforces core boundaries. Depending on the system, privileged services, authentication components, boot code, security-critical libraries, and configuration may also belong to it.

“Trusted” does not mean “known to be harmless.” It means that a failure or compromise in that component can violate the security goal.

Suppose a small service has permission to read a secret and returns a carefully limited result to other programs. Those programs do not need direct access to the secret, but they must trust the service to enforce its interface correctly. The service has become part of the TCB for that secret.

A smaller TCB is generally easier to inspect, test, and defend. Giving a large application unrestricted authority expands the amount of code whose correctness the system must trust.

This is one reason operating systems separate privileged mechanisms from ordinary applications. The separation does not make the trusted components perfect, but it reduces how much untrusted code can directly make system-wide decisions.

Protection decisions rely on knowing who or what is making a request, but identity and permission are different concepts.

Authentication establishes an identity. A login mechanism might verify that a person controls a credential. A service manager might start a process with a configured system identity.

Authorization decides what an authenticated identity may do. Successfully proving an identity does not imply permission to access every object.

Accountability connects actions to identities through records that can be examined later. Logs and audit records can help explain which subject attempted or completed a sensitive action.

The relationship is:

Establish identity, use that identity and the policy to decide access, then record the relevant actions when accountability is required.

A user may authenticate successfully and still be denied access to another user's private data. Conversely, an authorization rule is unreliable if the identity on which it depends can be forged.

Accountability is not a substitute for prevention. A log entry showing that a credential was stolen does not restore confidentiality. It is nevertheless part of a broader security design because detection and investigation matter when prevention is imperfect.

Isolation means that one protection domain does not receive unrestricted access to another. Separate process address spaces are a familiar example: an address used by one process does not grant that process the ability to read the memory mapped for another.

Strong isolation alone is not enough for a useful operating system. Programs need to exchange data, access shared files, use devices, and communicate over networks. Protection mechanisms make those interactions explicit and controlled.

Consider two processes that must exchange work:

Process A's private state reaches process B's private state only through a controlled communication channel.

The communication channel crosses the isolation boundary in a defined way. It does not require either process to receive unrestricted access to all of the other's memory.

This principle appears throughout secure system design:

Keep components separate by default, then grant only the specific interactions the system requires.

Boundaries also limit fault propagation. If the image worker crashes, corrupts its own memory, or processes malicious input, isolation can keep that failure from directly becoming memory corruption in the payment service.

Isolation cannot control what a recipient does with information after it is intentionally shared. Once the payment service sends a record to another process, the operating system may protect the recipient's copy from third parties, but it cannot make the recipient forget the bytes. Secure sharing therefore requires both an enforced channel and a correct decision to disclose the data.

The principle of least privilege says that a subject should receive only the authority it needs, for only as long as it needs it.

Least privilege does not promise that the subject will never be compromised. It changes what happens after compromise.

If an image worker needs to read uploaded images and write derived thumbnails, giving it access to every customer record does not help it perform its job. It only increases the damage possible from a bug or attacker.

The same reasoning applies to time. A process that needs elevated authority only during startup should not necessarily retain that authority for its entire lifetime. Reducing persistent privilege reduces the opportunity to misuse it.

Least privilege is valuable even in systems without a human attacker. A service with narrow authority is less likely to damage unrelated files through a path bug, configuration mistake, or unexpected input.

Applying the principle requires understanding the program's real dependencies. Granting too little can break legitimate work; granting too much weakens containment. The goal is precise authority, not minimum functionality.

A secure default is to deny an operation unless the policy grants it. This is sometimes called a fail-safe default.

An allow-by-default design depends on identifying every dangerous case. A deny-by-default design requires identifying the intended paths. Neither approach removes the need for correct configuration, but default denial is safer when a new object, operation, or component appears unexpectedly.

Protection decisions must also be checked at every relevant access, a principle known as complete mediation.

This does not necessarily mean repeating an expensive, full policy calculation for every byte read. Operating systems often validate an access when creating a kernel-managed handle and then ensure later operations cannot exceed the authority represented by that handle.

The important requirement is that no usable path escapes the enforced decision. If the kernel grants a reusable handle, the policy must define which authority that handle carries, how long the authority lasts, and whether later policy changes revoke it.

Default denial answers what to do in the absence of permission. Complete mediation ensures that the answer cannot be avoided by choosing a different path.

No single protection mechanism should be treated as infallible.

Defense in depth uses independent layers so that one mistake does not immediately produce the worst possible outcome. A network-facing service might have narrowly scoped operating-system authority, validate application requests, keep secrets separate from public data, and produce security-relevant logs.

Each layer addresses different assumptions. Application authorization can decide whether a customer may view a particular order. Operating-system isolation can stop the service from reading unrelated process memory. Operational monitoring can reveal unexpected behavior that preventive controls did not stop.

Layers are useful only when they add meaningful, independent resistance. Repeating the same incorrect assumption in three places is not strong defense. If several controls all trust the same compromised component, they can fail together.

Defense in depth also does not justify careless outer layers. It acknowledges that complex systems contain bugs and configuration errors, then tries to keep any one failure from becoming a complete compromise.

Consider a host running three components:

The intended protection policy can be summarized as follows:

This separation matters when the public API parses an attacker-controlled request. If the API is compromised, operating-system protection cannot repair its application logic. It can, however, prevent that process from directly opening the worker's credential or modifying the worker's executable, provided the policy and mechanisms are correct.

The payment worker's narrow interface creates another boundary. The API can request a defined payment operation without receiving the raw credential. The worker must still validate that requests match its intended contract; otherwise, an attacker may misuse its legitimate authority through the interface.

Now consider several possible failures:

The example shows the main relationship:

Protection reduces authority and contains failures. Security evaluates whether the complete arrangement protects the assets that matter.

A security claim is meaningful only under stated assumptions. “This service is secure” is too vague to evaluate.

A threat model identifies the assets to protect, the actors or failures that might harm them, the capabilities available to those actors, and the boundaries the design trusts.

For the backend service, customer transaction data and the payment credential are assets. Untrusted network clients can send arbitrary requests but are not assumed to control the kernel. The public API processes hostile input. The payment worker is trusted to use its credential only through its narrow interface.

Those assumptions reveal where protection is useful. The API should not inherit authority merely because it runs on the same host as the worker. Communication between them crosses a trust boundary and needs a defined contract.

Three related terms help describe failures precisely:

A threat is a potential cause of harm, such as an attacker seeking customer data. A vulnerability is a weakness that could be exploited, such as an incorrect boundary check. An attack is an attempt to exploit a weakness or otherwise violate a security goal.

Threat models are intentionally scoped. A design that protects against an untrusted application may still assume correct processor behavior and an uncompromised kernel. Changing those assumptions can change which protections are sufficient.

The operating system has strong control over low-level resources, but it does not automatically know the meaning of every action.

It can determine that a process is permitted to read a file. It usually cannot determine that a particular line in that file is appropriate for the current customer.

It can isolate two address spaces. It cannot prevent an authorized process from intentionally copying a secret into a message it is allowed to send.

It can deny an unprivileged device operation. It cannot guarantee that privileged software will use the device correctly.

It can contain many faults. It cannot make every trusted component correct or keep a service available under every possible failure.

This is not a weakness in the definition of protection. It is the boundary of what the mechanism understands. Good security design assigns each decision to a layer that has enough context to make it:

The layers must agree. An application cannot enforce its rules if the operating system lets unrelated processes rewrite its code or data. Operating-system isolation cannot preserve confidentiality if the authorized application sends data to the wrong client.

Protection controls which subjects may perform which operations on operating-system objects. Its purpose is controlled sharing, isolation, and fault containment.

Security is the broader goal of preserving confidentiality, integrity, and availability despite mistakes, misuse, and attacks. Protection is one of its essential foundations.

Policy defines what should be allowed; mechanism enforces that decision. A security failure can result from a bad policy, a broken mechanism, incorrect application behavior, or a false assumption about the threat model.

Reliable protection requires a trusted enforcement boundary. Least privilege, default denial, complete mediation, a small trusted computing base, and defense in depth all reduce the impact of failures.

The operating system can control access to resources, but it cannot determine every application-level meaning or intent. Secure systems align kernel protection with correct application logic and sound operational policy.