Discretionary access control weaknesses, multilevel security, and integrity models

Contents

Access control, confidentiality, and integrity

Security mechanisms answer different questions. Identity-based permissions determine who may access an object; information-flow models constrain where data may move; integrity models restrict how less trustworthy influence reaches critical state. The distinctions matter because a mechanism can enforce its own rule correctly while leaving a different security objective unresolved.

Acronym and notation glossary

Acronyms are expanded when they first become important in the article. This glossary also covers abbreviations that appear only in the complete source appendix. Hover or focus an underlined abbreviation elsewhere on the page to see its expansion.

1. The Morris Worm: exploitation and damage

D4–16 · background, attack vectors, propagation, and containment

What makes a worm a worm?

A worm is self-propagating malware. Its essential cycle is find targets → compromise a target → copy itself and execute → repeat. Propagation can itself cause damage. A program does not need a file-deletion routine to exhaust CPU, memory, process slots, or network capacity.

The article’s historical example is the November 1988 Morris Worm, written by Robert Morris Jr. The biographical source material notes that his father worked as chief scientist at the NSA’s National Computer Security Center. The security lesson is the combination of several ways into a machine with the broad permissions available once code is running.

Two cooperating components

The main program searched for other machines and tried infiltration methods. A small vector program, described as 99 lines of C, was compiled and run on a compromised machine to transfer the main program. Think of the vector as a bootstrap: the first foothold only needs enough functionality to obtain and start the larger program.

Why the fingerd overflow matters to access control

A buffer reserves a bounded area of memory. A read function that does not check the input length may keep writing beyond it. In the article’s example, the excess input changes where the program returns, so the attacker’s instructions run instead of the intended continuation. The key access-control observation comes after this mistake: the kernel still sees a process running under the daemon account. It does not infer that the instructions now express an attacker’s intent.

According to D11, the fingerd entry ran as daemon, not root. That is a useful limit, but it still allowed substantial activity. Root access was not required for this propagation path. If a program-specific policy prevented the daemon from executing a shell, the particular shell-based chain described in D16 would fail. This does not prove that every conceivable attack on the daemon would fail.

Remote trust, step by step

1. A host accepts logins from certain accounts on another host without a fresh password challenge.
2. An attacker gains control of a trusted account or host.
3. The attacker presents a request that satisfies the configured trust rule.
4. The receiving host honors the rule, so compromise can spread across that trust relationship.

System-wide trust appears in /etc/hosts.equiv; user-specific trust appears in ~/.rhosts, with a root home-directory variant on older systems. D10 spells the system file /etc/host.equiv, while the supplementary notes use hosts.equiv. Reciprocal trust was a heuristic: “X trusts Y” does not logically imply “Y trusts X.” The worm tried this assumption because it could expose more targets.

The article describes reading historical /etc/passwd password hashes and testing guesses offline. A dictionary attack tries likely passwords rather than every possible string. Account access mattered because the daemon identity alone did not provide the regular user’s remote-login privileges. These are historical password-storage and remote-login examples, not instructions about present systems.

Hiding, parallelism, and repeated infection

The notes explain that the worm made its process name appear as sh and opened then unlinked its files. This illustrates an important filesystem behavior: removing a directory entry does not immediately destroy data still referenced by an open file. The worm searched routing information using netstat -r -n and host information such as /etc/hosts. A successful connection led to a child handling infection while the parent continued searching.

Repeated copies consumed resources until machines became slow or unusable. D13 gives a 1/8 probability of proceeding even after a host reported an existing infection. Its supplementary notes say 1 in 7. Keep that inconsistency visible: use the displayed 1/8 when answering a question explicitly based on D13, and focus on the mechanism rather than silently treating the two values as equal.

What better access control can and cannot do

D16 says the DEBUG and desired mutual-trust behavior cannot be stopped by access control. Read this in context: a policy that deliberately permits those operations will not reject a request merely because its purpose is hostile. Removing the unsafe feature, narrowing trust, or adding a separate confinement policy changes that context. D16 also reverses the earlier vector numbering; refer to each vector by name.

D14 generalizes compromise to buggy network daemons, vulnerable browsers/mail clients, readers of downloaded files, configuration errors such as weak passwords and DEBUG options, social engineering, running malicious attachments or Trojan programs, and physical access. Preventing entry and limiting post-entry authority solve different parts of the problem.

2. Discretionary access control, the confused deputy, and capabilities

D17–32 · with access-matrix review

Discretionary access control (DAC) lets an authorized subject propagate rights at its discretion, often through object ownership. The article’s Trusted Computer System Evaluation Criteria (TCSEC) definition includes identity and need-to-know, with direct or indirect passing of permissions. A Unix file owner granting access is a familiar instance. “Discretionary” describes control over rights; it does not mean access checks are optional.

The compiler serves two masters

The compiler SYSX/FORT needs authority from its administrator to update SYSX/STAT and SYSX/BILL. It also accepts an output filename from the invoking programmer. The programmer can choose the name SYSX/BILL without having permission to write that file directly.

1. The administrator gives the compiler billing authority for a legitimate purpose.
2. The user asks the compiler to place ordinary compilation output in SYSX/BILL.
3. The compiler resolves that filename using its available authority.
4. The write succeeds because the compiler has billing rights, corrupting or erasing billing information.

The deputy is the compiler. The confusion is about whose authority should justify this particular write. The compiler need not be malicious or suffer a buffer overflow. It can faithfully perform an operation using the wrong source of authority.

A filename designates an object but does not itself prove that the caller may access it. This separation creates the danger when an operation combines an attacker-chosen name with authority acquired for a different purpose.

Three meanings of “capability”

One matrix, three representations

Access-control lists (ACLs) encode columns: F stores U’s rights; G stores U’s read right and V’s read/write/own rights. Capability lists encode rows: U holds F/read, F/write, F/own, G/read; V holds G/read, G/write, G/own. Access-control triples encode cells: (U, read, F), (U, write, F), (U, own, F), (U, read, G), (V, read, G), (V, write, G), (V, own, G). The article notes that triples fit relational database storage. These encodings describe the same permissions; their organization supports different lookups.

The capability solution, with explicit authority selection

The caller must supply an output capability, not just an arbitrary output name. The compiler stores its statistics capability in slot 1, billing capability in slot 2, and the caller’s output capability in slot 3. Output code uses slot 3. The caller cannot supply a billing capability that it does not hold.

statistics update → use slot 1 → SYSX/STAT
billing update    → use slot 2 → SYSX/BILL
ordinary output   → use slot 3 → caller-authorized output

The protection depends on keeping these uses distinct. Code that deliberately substitutes slot 2 for slot 3 can still misuse its real billing authority. The design removes the need to search all ambient authority just to resolve the requested output operation. The article’s illustrative Unix variant allows only owners to open files and shares access by passing already-open file descriptors; it is a hypothetical capability-style sharing design, not a claim about ordinary Unix file-opening rules.

Ambient authority and naming

Ambient authority is authority automatically available without selecting its source for the operation. In the source material’s banking analogy, showing an ID unlocks access to every account for which you are authorized; choosing a name can accidentally charge the wrong one. In the token analogy, you present the account’s passport and PIN, explicitly identifying the account authority being exercised.

The supplementary notes use a secretary working for two faculty members with the same surname. If the secretary has general authority over both accounts, a naming mistake can charge the wrong account. Associating each request with its own account token makes the intended authority explicit.

ACL systems need names for objects and for the users/groups they list. Capabilities can combine object designation and authority in one reference. D31 argues that large, changing populations of process-level subjects make identity-based policy management difficult; many ACL systems therefore use relatively stable user accounts. D32 offers conjectures about capability adoption: passing references suits process sharing but can complicate user-level sharing and couple cooperating programs. These are design tradeoffs in the article, not a measured claim that capabilities are absent from modern systems.

3. Trojan horses and the process–principal gap

D18, D33–44 · three related but distinct DAC weaknesses

Why perfect per-file checks can still leak information

B provides a useful-looking program named Goodies. A runs it. The Trojan component reads F using A’s authority, copies the data into G using A’s authority, and lets B read G using B’s own rights.

F ──read allowed for A──▶ Goodies running as A
                         │
                         └──write allowed for A──▶ G ──read allowed for B──▶ B

Every individual DAC check can succeed correctly. The missing constraint is on the flow of information from F to G. Revoking B’s direct access to F does not stop the copy. Even if A is honest, A’s program can be malicious. Replacing explicit malware with an exploited reader produces the same authority problem.

Who is actually responsible for a request?

A subject is the executing process that asks to read or write. A principal is an identity whose authority or influence should matter. Traditional Unix checks largely associate a process with its effective UID. The article asks whether this one identity captures everyone whose intentions may control the request.

The first implicit assumption is benign software: programs perform the user’s intended task rather than hidden malicious actions. The second is correct software: programs safely handle input, so an input provider cannot inject behavior through a vulnerability. A program can be benign but incorrect, or intentionally malicious even if its implementation works exactly as its author intended.

D42–43 argues that this weakness is not simply “owners may set permissions.” It is also an enforcement problem: the process can act under several parties’ influence while the system attributes the request to one invoker. More principled origin tracking can treat the program provider and input providers as relevant principals and conservatively account for uncertainty.

Match each proposed fix to the failure

D44 names Usable Mandatory Integrity Protection (UMIP) and Information Flow Enhanced DAC (IFEDAC) as research directions. Its notes cite Li, Mao, and Chen (2007) and Mao et al. (2011). The source notes do not specify their full algorithms; do not invent a precise enforcement rule from the acronym alone. The article’s claim about limited commercial deployment belongs to its historical context.

4. Confinement and program-based restrictions

D45–54

The goal of sandboxing, virtualization, and isolation is to limit damage even after a program is compromised. Instead of relying entirely on perfect software, choose a boundary that restricts the resources an attacker-controlled process can reach.

What chroot changes

A process normally resolves an absolute pathname starting at its root directory. chroot changes that root for the process and its children. An administrator builds a limited filesystem tree, such as /chroot/named, then arranges for the daemon to see that directory as /. Its visible /etc now refers to the restricted tree’s etc.

Host view                         Confined process view
/chroot/named/                    /
/chroot/named/etc/service.conf     /etc/service.conf
/chroot/named/lib/                 /lib/

If a fingerd environment lacks a shell, compiler, or useful host files, the worm’s expected propagation chain may fail at those steps. But changing pathname lookup does not automatically prevent networking, resource exhaustion, or all interactions with other processes.

D50 explains why chroot requires privilege in the historical Unix model: an ordinary user could otherwise build a fake filesystem environment to mislead a privileged program, for example with a fabricated password file. It also warns that privileged processes can escape some chroot setups and that chroot alone supplies no CPU, bandwidth, disk-space, or I/O quota.

What a virtual machine does not solve

D51 describes a virtual machine (VM) using hosted emulation and runtime binary translation, with VirtualBox and VMware as examples, and labels the overhead significant. Treat those implementation/performance details as historical examples, not universal properties of every VM. The durable point in D52 is that isolation is relative to a boundary: placing an untrusted Portable Document Format (PDF) reader and confidential files in the same guest can preserve the original within-guest exposure.

Program-based controls supplement user-based DAC. In a simplified combined decision, allowed = DAC allows AND program policy allows. The same user can launch two programs with very different legitimate needs. The challenge is writing a policy broad enough for intended work and narrow enough to restrict attacker behavior.

5. Security-Enhanced Linux and AppArmor policy examples

D55–64

Security-Enhanced Linux (SELinux): domains, types, classes, and operations

The article introduces SELinux as a system for finer, flexible mandatory policies, historically developed by the National Security Agency (NSA) and Secure Computing Corporation. It mentions deployment in Linux distributions and Android. Its central idea is to consider more than the user identity when authorizing a request.

A matrix with every process and every individual object is too large to administer directly. Domain-type enforcement groups subjects into domains and objects into types. The decision considers:

1. the subject’s domain, such as sshd_t;
2. the object’s type, such as sshd_tmp_t;
3. the object class, such as file, socket, or interprocess communication (IPC) object;
4. the requested operation, such as read, execute, create, or unlink.

allow sshd_t sshd_exec_t:file { read execute entrypoint }
allow sshd_t sshd_tmp_t:file { create read write getattr setattr link unlink rename }

Read the first rule as: a process in domain sshd_t is allowed those listed operations on file-class objects of type sshd_exec_t. entrypoint concerns use of an executable as an entry point into a domain. It is not a general permission to run all programs. The second rule allows the listed file-management operations on sshd_tmp_t objects, not on every temporary file.

Where labels come from

type_transition initrc_t sshd_exec_t:process sshd_t
type_transition sshd_t tmp_t:notdevfile_class_set sshd_tmp_t

The first article rule specifies a resulting process domain based on the source domain and executable type. The second specifies a resulting type for newly created objects using the creator’s domain and the parent directory’s type, for the named class set. A transition rule specifies a label; it is not by itself every permission required to execute or create. The names and syntax here come from the historical source material. D58’s example /etc/shadow → etc_t is an illustrative label, not a promise about a current installation.

Strict versus targeted policy

D61 contrasts strict policy, aiming to confine the whole system, with targeted policy, concentrating on selected daemons. Strict policy’s administrative difficulty matters: a policy that breaks ordinary use invites disabling or excessively broad exceptions. The source material references Fedora Core 2 and 3, so its deployment claims are historical.

AppArmor: reading the supplied profile

AppArmor associates a program with a profile describing allowed activity. D63’s example is for /usr/bin/foo. It includes shared abstractions and tunables, capability and network rules, path rules, and a subprofile called bar. The key contrast here is SELinux’s type/domain-oriented example versus AppArmor’s path-oriented profile example.

Permission key: r read; w write; m executable mapping; l hard-link creation; k locking. ux executes unconfined; px uses a separate profile. * stays within a path component while ** can span directories. The full historical profile text is retained in the source appendix. These meanings are clarified using the AppArmor profile manual; this is a reading exercise, not a deployable security profile.

6. Bell–LaPadula: the system, the policy, and access decisions

M5–17 · Bell–LaPadula (BLP) and multilevel security (MLS)

Why mandatory control enters the story

Multilevel security (MLS) means processing information at different sensitivities on a system used by people with different clearances and needs-to-know, while preventing unauthorized disclosure. Subjects/users have clearances; objects have classifications. The simple hierarchy is Top Secret > Secret > Confidential > Unclassified.

A mandatory policy limits what users can do even with objects they create. If A reads a classified file, A cannot simply grant B a right that overrides the system’s information-flow restriction. BLP was introduced in 1973 in the context of concerns about classified information in time-sharing systems, including bugs and accidental misuse.

Model, policy, verification

• System model: the abstract description of entities and actions.
• Security policy: the condition that defines acceptable behavior.
• Verification: an argument that the modeled system satisfies that condition.

The article describes a security model as system model plus security policy, supported by verification techniques. These are separate questions: a correct proof of a poorly chosen policy does not establish the desired real-world goal.

BLP models a computer as a state-transition system. A state records objects, an access matrix, current accesses, and labels. There is a set of subjects, with some designated trusted. The notes assume a fixed subject set. Transition rules describe changes such as acquiring access, releasing it, or modifying labels.

The three properties in the article

The familiar mnemonic is no read up, no write down. Use it with care: the article distinguishes maximum clearance from current level, and read access must satisfy both relevant conditions. A label comparison alone does not grant access when the discretionary matrix denies it. M15 uses “iff” within each property; the full decision is the conjunction of the applicable properties.

For an untrusted subject at a fixed current level, reads may bring information upward from lower objects; writes may move information upward to higher objects. Reading and writing the same object requires equality with its current level in the simple linear-label case. We assume the usual well-formed relation LC ≤ LM. Here “write” means the article’s write-only operation; a read-and-write operation must pass both checks.

How the star property blocks Goodies

If Goodies must operate at Secret to read F, it cannot write the secret contents to an Unclassified G under the star property. If it instead operates at Unclassified, its current-level read restriction prevents reading F. The two permissions needed for the direct copy are never available together at those labels.

Trusted subjects and trusted humans

M15 exempts designated trusted subjects from the star property. In this article’s formulation they still face the simple-security and discretionary requirements. A trusted subject is relied upon to handle otherwise unsafe flows correctly; it is not automatically proven harmless. The scheduler is a motivating example in the notes.

The star property applies to processes, not to all human behavior. A person who sees a secret could repeat it outside the computer. The model assumes authorized humans obey the relevant secrecy obligations, while their software may contain Trojan code. This is an explicit scope boundary.

7. Why secure states may still allow an insecure history

M19–25 · a central conceptual difficulty

The across-state counterexample

A snapshot may look secure even though the process remembers something learned earlier. In M20, s1 has maximum/current High and reads a High object o1. A second subject s2 and object o2 are Low. The leak happens when s1 changes level after ending its read.

The problem is the combination of remembered information and an unconstrained label change. The article is criticizing the sufficiency of the presented snapshot conditions for the intended information-flow objective. Do not interpret it as “all formulations of BLP permit arbitrary insecure relabeling.” Transition restrictions are part of what a complete model must specify.

Tranquility and history-aware labels

M20 proposes preventing current-level changes, or at least preventing a subject from dropping below the highest level it has read. At scalar levels, a history label can follow current ← max(current, level read), bounded by maximum clearance. With categories, replace max with a lattice join. A process that has read Secret cannot later act as Unclassified while retaining that information.

A correctly designed fresh low process or trustworthy sanitization mechanism requires its own argument about retained state and permitted flow. Simply closing a file or changing the displayed label is not enough. This is why policy must cover state transitions, not just the inequalities on a single request.

Why the article also says “not necessary”

M21 considers A writing High information into a Low file f. That violates the star property. But if only A can access f and no lower-cleared subject or externally visible sink ever receives it, the intended unauthorized disclosure may never occur. Thus the BLP snapshot rule can reject some histories that do not actually expose the information to an unauthorized observer.

Not sufficient: passing the listed state conditions may still allow the remembered-information sequence. Not necessary: violating a state condition need not cause disclosure in every surrounding system. The two claims compare the formal predicate with the intended disclosure goal. They do not mean the star property is useless.

State-sequence reasoning

M22 suggests distinguishing externally visible objects, such as a printer, from internal memory objects, and defining security over entire state sequences. Ask whether any information path leads from a High object to a Low subject or observable output. This captures a temporal relationship that a snapshot of current file accesses may miss.

The Basic Security Theorem, with the induction exposed

1. Base case: show the starting state q0 satisfies the chosen security predicate P.
2. Induction hypothesis: assume the state qn after n actions satisfies P.
3. Induction step: show every possible next action from that reachable state leads to q(n+1) satisfying P.
4. Conclusion: P holds after every finite sequence of actions.

For the reverse direction, if every reachable state is secure, the start and the targets of actions in actual executions are secure. The source material emphasizes this meaning of “action.” One does not need to establish properties of unreachable transitions merely because they appear syntactically in a larger transition relation.

The theorem is a general invariant-preservation argument. It would also prove “every reachable state has a nonnegative counter” if that were the predicate. It cannot prove that the predicate adequately defines confidentiality. M24 attributes this criticism to John McLean’s work from 1985, 1987, and 1990.

M25 credits BLP with an influential method for formal security reasoning, a state-transition model incorporating subjects/objects/labels/access matrices, and the star property showing why clearance checks alone are insufficient.

8. Overt channels, covert channels, and BLP’s limits

M27–30

An overt channel uses an ordinary communication operation, such as writing a file another process reads. A covert channel repurposes an observable shared resource that is not intended as that communication path. BLP’s object read/write restrictions do not automatically account for every resource that can carry a signal.

The necessary ingredients are influence and observation: one party can affect some state or timing and another can detect the effect. The article assumes cooperating high and low subjects with an agreed encoding. Ordinary background activity creates noise, but repetition and error-correcting codes can still allow communication.

The notes’ prisoners example encodes information in apparently innocuous messages, such as odd/even word lengths. Its purpose is to show that allowed-looking activity can carry a second meaning agreed by the communicating parties.

M30 says eliminating every covert channel is generally extremely difficult, so systems may try to bound bandwidth. It mentions historical military use of hardware cryptographic components to reduce the possibility of software Trojan leakage of keys. This is a article example, not a verified statement of current procurement rules, and hardware is not a universal proof against all channels.

BLP also does not establish integrity. A low subject’s write upward can be allowed by the confidentiality inequalities and still damage an important high object if other controls allow it. Whether information may be disclosed and whether data may be corrupted require different arguments.

9. Categories, dominance, and security lattices

M31–35

A single ranking is often too broad. A Top Secret clearance for one project should not automatically grant every other project’s secrets. Categories, also called compartments, represent separate needs-to-know: military examples include army/navy/air force and the labels NATO/NASA/NOFORN used in the article; commercial examples include Sales, R&D, HR, and departments.

A full label is (level, set of categories). Typical commercial levels in M31 are restricted ≥ proprietary ≥ sensitive ≥ public. The mathematical construction uses all category subsets, including the empty set.

Both tests must pass. A higher rank does not compensate for missing a category. An object marked (Secret, {army, navy}) requires both army and navy authorization, not either one.

Why this is a partial order

Reflexive: each label dominates itself. Antisymmetric: if A dominates B and B dominates A, their levels and category sets are equal. Transitive: if A dominates B and B dominates C, A dominates C. It is not generally a total order because two labels may be incomparable.

Why it is a lattice: joins and meets

A lattice gives every pair a unique least upper bound (join) and greatest lower bound (meet). For these labels:

join((e1,C1),(e2,C2)) = (max(e1,e2), C1 ∪ C2)
meet((e1,C1),(e2,C2)) = (min(e1,e2), C1 ∩ C2)

The join is the least label sufficient to cover information from both inputs. If a process combines (Secret, {army}) and (Top Secret, {navy}), the join is (Top Secret, {army, navy}). A lower scalar level would miss the second source’s rank; omitting either category would miss part of the information. Their meet is (Secret, {}).

Counting labels

For k independent categories, each category is either included or excluded, so there are 2k subsets. With n scalar levels, the product contains n × 2k labels. M33’s four levels and five categories give 4 × 32 = 128 labels. This assumes the full product, with no excluded combinations.

Applying BLP with categories

Replace ≥ by dominates. For an untrusted subject, both maximum and current labels must dominate the object for a read. For a write, the object must dominate the current label. If current is (Secret, {army}), writing (Top Secret, {navy}) is denied: the destination is higher in rank but lacks army. The access matrix remains an additional gate.

M35’s need-to-know says that clearance alone is insufficient; access should be needed for official duties. Categories provide compartment restrictions, and DAC can further restrict particular documents. Least privilege asks more broadly that an actor receive only the authority needed for its task.

10. Trust, the trusted computing base, and the reference monitor

M37–42

Trusted means the system’s security depends on a component. If it fails or acts maliciously, the policy can fail. Trustworthy means the component deserves that reliance because of properties such as correct implementation. The first describes its role; the second describes its quality.

The trusted computing base (TCB) includes all hardware, software, and procedural components on which enforcement of the chosen policy depends. The source notes list hardware, kernel, system binaries/configuration, boot-related components, and setuid-root programs as typical Unix dependencies. Exact membership depends on the security objective and architecture.

For protecting a password entered at a login prompt, the input path and login/OS machinery matter. For protecting webmail or online banking information, the browser processing those credentials/content joins the relevant dependencies. “The browser is outside the TCB” has no meaning without specifying the objective and possible access paths.

M38’s “smaller TCB means more secure” expresses a design direction: fewer dependencies can make review and assurance more tractable. Size alone is not a mathematical guarantee of security. A tiny but incorrect monitor still fails.

Assurance and kernelized design

Assurance is confidence that a system will not fail in the specified way, supported by architecture, development process, developer practices, and technical assessment. A small security kernel can centralize enforcement and reduce the code whose correctness must be trusted.

A reference monitor mediates relevant accesses. M40’s idealized diagram places it within the TCB, with user requests passing through its security checks. The aim is that security need not depend on all ordinary kernel functionality. The article notes that most operating systems are not built exactly this way. Merely placing a box labeled “reference monitor” inside a large privileged kernel does not prove the surrounding code cannot subvert it.

Assurance criteria such as TCSEC and Common Criteria give a framework for evaluation. Their origin in military needs does not mean every evaluated system must use the same security policy.

11. Security evaluation: TCSEC and Common Criteria

M43–59 · historical evaluation frameworks and careful interpretation

Trusted Computer System Evaluation Criteria (TCSEC) / Orange Book

The Trusted Computer System Evaluation Criteria, shown as 1983–1999 in M43, came from the US Department of Defense’s National Computer Security Center (NCSC). It emphasizes confidentiality, Bell–LaPadula (BLP), and the reference monitor. Related Rainbow Series publications included network and database interpretations.

Object reuse means preventing a newly assigned resource, such as storage, from exposing a previous user’s residual data. A trusted path provides a protected way to interact with security functions rather than an easily impersonated interface. These requirements address ways security can fail outside a simple file-permission lookup.

Functionality versus assurance

Functionality: what protections exist? Assurance: how much justified confidence do we have in those protections? M48’s plot places B3 and A1 at similar functionality with A1 further along the assurance axis. Functionality has several dimensions: confidentiality, integrity, auditing, authentication, availability, and more. A single linear score hides those distinctions.

M47 criticizes TCSEC for focusing on operating systems and BLP-style confidentiality, omitting important commercial integrity/availability goals, and combining functionality and assurance in one scale. “Most commercial firms do not need MAC” is the article’s broad historical criticism of that evaluation focus, not a rule that commercial deployments never benefit from mandatory controls.

Common Criteria: separating requirements from evaluated products

The article introduces Common Criteria as the ISO/IEC 15408 framework, with recognition arrangements beginning in 1998. Its December 2015 country counts—19 authorizing and 8 consuming—and its listed editions/classes are historical source material facts, not current status. The durable idea is a framework in which requirements can be specified, claimed, and evaluated rather than one fixed list of product features.

A PP itself can be evaluated. The article’s Controlled Access PP example includes authentication, user-data protection, prevention of audit loss, testing, administrator guidance, and lifecycle support. Its assumptions include well-managed non-hostile users and exclude malicious developers. Those assumptions delimit the claim; they are not details to ignore.

All requirement classes named in the source notes

Functional classes (M51): Security Audit; Communication; Cryptographic Support; User Data Protection; Identification and Authentication; Security Management; Privacy; Protection of Security Functions; Resource Utilization; TOE Access; Trusted Path. The Identification and Authentication example contains families for Authentication Failures, User Attribute Definition, Specification of Secrets, User Authentication, User Identification, and User/Subject Binding.

Assurance classes as listed in M52: Protection Profile Evaluation; Security Target Evaluation; Configuration Management; Delivery and Operation; Development; Guidance Documentation; Life Cycle; Tests; Vulnerabilities Assessment; Maintenance of Assurance. Learn what the distinction means: requiring authentication is functionality; examining its design and tests is assurance. This taxonomy reflects the article’s version of CC.

The seven EAL descriptions in the article

M58 warns against interpreting a higher EAL as automatically stronger security features. It states that more stringent assurance requirements were met, under the evaluated assumptions. Its remarks that below EAL4 “doesn’t mean much” and above EAL4 is hard for complex operating systems are the articler’s evaluative judgments, not definitions or universal laws.

M59 criticizes cost, documentation burden, delayed evaluation relative to product changes, and limited industry influence. These are the article’s criticisms, including its historical cost estimates, rather than present-day price quotations. The conceptual caution remains useful: inspect the TOE boundary, ST, assumptions, configuration, and claimed functions before comparing two ratings.

12. Biba: five policies, five different behaviors

M61–70 · do not collapse them all into “BLP reversed”

What does integrity mean?

The article contrasts data integrity, described as detecting data changes, with system integrity: keeping critical state and actions correct. M62 tests increasingly useful definitions. “Critical data never change” prevents legitimate updates. “Changes only in correct ways” needs a definition of correct. “Changes through trusted programs” identifies an enforcement route, but requires justification for trusting those programs. “Changes as intended by authorized users” also requires relating the program’s behavior to authorized intent.

Biba gives subjects and objects integrity levels, totally ordered in these source notes. Higher subject integrity reflects greater confidence in a program’s behavior; higher object integrity can reflect confidence in the data. These are separate from confidentiality levels. An unverified intelligence report can be extremely secret but unreliable. A published public key or root certificate may need very high integrity even though its contents are public.

For all examples here, use High = 3, Medium = 2, Low = 1. A read carries influence from object to subject. A write carries influence from subject to object. Derive the rule from the direction of influence rather than memorizing an arrow without meaning.

12.1 Strict integrity

A high-integrity process must not base its actions on low-integrity input, and a low-integrity process must not modify high-integrity data. The first prevents indirect contamination; the second prevents direct modification from below. These constraints oppose BLP because BLP protects secrets from going downward while strict Biba protects trust from being polluted upward.

Strict integrity is restrictive because useful systems need external inputs: banks must accept deposit requests, and operating systems must receive network data. If all external data are Low, strict no-read-down prevents high-integrity services from examining them. Trusted validation requires an explicitly justified exception or a different policy, not simply labeling arbitrary external input High.

12.2 Subject low-water mark

The subject records the lowest integrity of information it has consumed. It loses authority to write important objects after reading less trustworthy data. Labels move downward; ordinary reads do not restore trust.

This is dual to a confidentiality history label that rises as a subject reads secrets. Confidentiality accumulates sensitivity upward; subject low-water integrity accumulates possible contamination downward. The policy prevents low-object influence from entering an object that remains protected as High.

12.3 Object low-water mark

A write from a lower-integrity subject is accepted, but the destination no longer carries its former high-integrity claim. This policy protects the meaning of labels rather than preserving the contents of every object initially labeled High.

M66 asks whether there is a path from low to high. Be precise about time: low can write an initially high object, but that operation lowers the label. Objects that retain High labels have not been contaminated through the modeled operations. This is unsuitable if “High” means a fixed asset must never be modified by Low subjects.

12.4 Low-water mark integrity audit

Both reads and writes are permitted, while labels trace possible contamination. The article compares this to taint tracking: it records influence rather than blocking the contaminated operation.

12.5 Ring policy

High subjects may consume Low input while retaining the ability to write High objects. The system therefore trusts those subjects to handle low-integrity input correctly. This makes useful input processing possible, but moves the obligation into the trusted program’s behavior. A vulnerable parser is dangerous because its label does not automatically drop after reading hostile input.

The complete policy comparison

M70 arranges these choices into a grid. The last row, “allow low write to high with no object downgrade,” is empty because it permits direct contamination while continuing to claim high integrity. The last column, “allow high read of low with no subject downgrade,” can contain ring policy because a high subject can be trusted to validate and interpret input. That is a trust assumption, not an automatic guarantee. The source notes also allow different policy choices for different subjects.

13. Why integrity needs trusted writers

M71–76

Quality and importance are different dimensions

M71 gives two interpretations of an object’s integrity level: quality/trustworthiness, which can fall after contamination, and importance/protection requirement, which should not drop merely because an attacker tried to corrupt the asset. The first asks “how reliable is this content?” The second asks “how strongly must we protect this object?”

A log can be important evidence yet contain unreliable attacker-supplied messages. A temporary file can contain high-quality data but be unimportant after the task ends. If a design uses a quality label to justify operations requiring a protection threshold, it should demand quality at least as high as the required threshold. There is no universal equality or ordering between the two independent attributes for every object. When quality falls below a required threshold, a system should not quietly treat the data as meeting that requirement.

The confidentiality/integrity asymmetry

For confidentiality in an ideal model, an untrusted reader can be prevented from disclosing a secret by blocking every path from that reader to an unauthorized observer. The reader cannot disclose the particular secret without first receiving it. In contrast, a writer can invent false data without receiving any bad input. Blocking low-integrity reads does not prove that the writer’s own code is correct or honest.

M73’s analogy says a person who knows a secret can be confined to prevent further disclosure, but a person issuing instructions can invent bad instructions even after isolation from outside influence. Within the article’s overt-flow abstraction, integrity therefore requires trust in critical writers.

M75 draws two implications: relying only on a tiny security kernel does not establish correctness of every application’s critical updates, and establishing trust in the relevant writers becomes a central challenge. Its statement that integrity needs “no worry” about covert channels is a model-level contrast: a trusted writer must already handle potentially bad influence correctly. It should not be generalized into a claim that covert influence is irrelevant in all real integrity systems.

Windows Mandatory Integrity Control example

M76 illustrates ring-like protection using Windows levels Low, Medium, High, and System. Normal-user processes are presented as Medium, elevated processes as High, and the historical Internet Explorer Protected Mode example as Low. The labels do not automatically change on reads or writes.

14. Clark–Wilson: trustworthy transformations

M78–84

Clark and Wilson’s 1987 model emphasizes commercial integrity: even an authorized user should not be allowed to alter assets or accounting records arbitrarily. The paper’s two conclusions, as presented in M78, are that commercial integrity requires a distinct set of policies, and that enforcing them requires mechanisms beyond the Orange Book’s disclosure-oriented approach.

Well-formed transactions

A well-formed transaction restricts changes to operations designed to preserve the system’s integrity rules. Users invoke trusted code instead of directly editing critical records. Examples in the article are password-changing programs, append-only transaction logs, and double-entry bookkeeping.

Internal versus external consistency

Internal consistency means the records satisfy the specified relationships. Double-entry bookkeeping can detect some errors because corresponding entries must balance. As the notes stress, balanced entries can still be wrong.

External consistency means records correspond to reality. An attacker might enter a fictitious equipment order, falsely record that it arrived, and pay an accomplice while all balances remain consistent. A program cannot establish actual delivery merely because someone entered “received.”

Separation of duty

Split a sensitive operation into parts performed by different people: one requests a purchase, another verifies delivery, and an authorized approver releases payment. The article’s two-person rule is a simple instance. The purpose is to require independent participation rather than let one individual fabricate every supporting step. Separation reduces unilateral fraud but does not make collusion impossible.

The four named components

A UDI is not automatically promoted to a CDI merely because someone copies it into the database. The transformation must validate or reject it according to the integrity specification. An IVP checks state; a TP changes state in an approved way. Do not swap their roles.

Four enforcement needs in M81

1. Control access to data: only the specified programs may manipulate each protected item.
2. Certify programs: inspect them for correct construction and control who installs or modifies them.
3. Control access to programs: authorize each user for only the appropriate procedures.
4. Control administration: inspect and restrict how users are assigned to procedures.

The first two establish the well-formed transaction boundary; the latter two support separation of duty. If an administrator can silently authorize the same person for every step, the intended separation can disappear.

Contrast with BLP: data are associated with allowed transformations rather than just sensitivity levels; users are authorized to invoke procedures rather than merely read/write data. Contrast with Biba: Biba tells us which integrity-level flows are acceptable but does not itself supply the process for establishing trustworthy critical writers. Clark–Wilson focuses on constraints, certification, and administration that support that trust.

15. Chinese Wall: permissions depend on history

M85–87

The Chinese Wall policy aims to prevent conflicts of interest. Organize data into three levels: individual objects → company datasets → conflict-of-interest classes. Competing companies share a conflict class. A subject’s first access in a class constrains later access to competitors in that class.

All objects
├─ Banking conflict class
│  ├─ Bank A dataset: forecasts, customer analysis
│  └─ Bank B dataset: forecasts, customer analysis
└─ Energy conflict class
   ├─ Energy X dataset: forecasts, contracts
   └─ Energy Y dataset: forecasts, contracts

M86’s original diagram uses conflict classes A, B, C, company datasets f/g/h, i/j/k, and l/m/n, with individual objects under each. The central idea is the hierarchy, not the letter names.

The simple-security rule in the source notes

An access is allowed if the requested object belongs to a company dataset already accessed by the subject, or it belongs to a conflict class in which the subject has not accessed a competing company dataset. For the first access, no conflicting history exists, so the subject can choose a company.

Apply the condition to the entire history. It is not enough for the new request to be in a different class from just the most recent object. Closing a file does not erase the conflict-of-interest history.

This differs from a fixed BLP clearance: two analysts with the same initial privileges can end up with different allowed requests after choosing different clients. The restriction evolves with access history.

16. Model comparison and applied reasoning

A repeatable method for scenario problems

1. Name the objective: confidentiality, integrity, availability, or conflict avoidance.
2. List subjects, principals, objects, rights, and initial labels/history separately.
3. State the policy variant and its assumptions.
4. Evaluate one operation at a time, checking all gates.
5. After each allowed operation, update labels/history if that policy requires it.
6. Trace the resulting information or modification path to the relevant observer/asset.
7. Explain the residual dependency: trusted code, accurate labels, prior input, other checks, or an unmodeled channel.

Applied scenarios with worked explanations

17. Readings, source limits, and source clarifications

The collected source material is the foundation of this article. The readings below are listed in the source material; their full texts were not included in the project and are not being represented as fully reviewed here. The online manuals cited in clarification boxes were used for the specific implementation distinctions indicated. Everything needed to use this article is embedded; opening external references is optional.

D2: DAC readings

• Seeley, A Tour of the Worm, Winter USENIX 1989. Connection: the worm’s entry and propagation mechanisms.
• Hardy, The Confused Deputy, ACM SIGOPS OSR, October 1988. Connection: binding an operation to the right source of authority.
• Miller et al., Capability Myths Demolished. Connection: capability semantics and the ACL comparison.
• Mao et al., Combining Discretionary Policy with Mandatory Information Flow in Operating Systems, ACM TISSEC, November 2011. D2 says reading the introduction is sufficient for this item. Connection: maintaining more of the origin/influence information lost by traditional DAC.

M2–3: security-model readings

• Bell and La Padula, Secure Computer System: Unified Exposition and MULTICS Interpretation, Section II.
• Biba, Integrity Considerations for Secure Computer Systems, MITRE MTR-3153, April 1977.
• Clark and Wilson, A Comparison of Commercial and Military Computer Security Policies, IEEE SSP 1987.
• Brewer and Nash, The Chinese Wall Security Policy, IEEE SSP 1989, listed as related reading.

Clarifications worth retaining

• D1: the original heading was tied to an earlier organizational label; the article retains the technical topic without that framing.
• D10: host.equiv in the source material versus hosts.equiv in the notes.
• D13: reinfection probability 1/8 in the displayed source material versus 1 in 7 in the notes.
• D16: attack vector numbering swaps sendmail and fingerd compared with D7–9.
• D44, D51, D55, D61: adoption, virtualization performance, distributions, and Fedora Core examples are historical/contextual.
• M15: each label condition must be combined with all applicable properties; do not use a single “iff” as the whole authorization decision.
• M20–24: the critique concerns the relationship between the presented state predicate and the intended information-flow goal.
• M49–59: country counts, requirement taxonomy, cost claims, and EAL judgments reflect the article’s context, not a current standards survey.
• M75–76: integrity/covert-channel remarks and the Windows ring analogy are model-level simplifications.
• M87: the source material provides the Chinese Wall simple rule, not the complete original policy.

D65 previews MLS, Biba, Clark–Wilson, and Chinese Wall, all covered in the second source collection. M89 previews noninterference/non-deducibility and role-based access control, but does not develop them in this article. They are retained in the appendix as previews rather than invented additional sections.

Technical reference appendix

This searchable appendix collects detailed technical statements and available commentary across 154 reference entries. Use it to locate an exact phrase or trace a concept to its reference identifier. Repeated outlines remain where they preserve context.

Discretionary Access Control: Reference Entries

Security Models: Reference Entries