Local and remote exploits, chroot jails, and what assurance actually buys

Two exploit classes, and one intrusion that uses both

A vulnerability's class is decided by one question: does the attacker already have code running on the machine?

A remote exploit is a flaw in something reachable across the network — a web server, a mail daemon, a database listener — that an attacker can trigger without any prior access. A local exploit is a flaw in something that only a party already executing on the system can reach; the classic case is a program that is setuid to root or setgid to a privileged group, because such a program runs with those elevated rights no matter who invokes it. A defect in one converts "I can run programs here" into "I am root here".

The two are complementary, not ranked, and a real intrusion generally uses one of each. On the Rideau Library catalogue server: an unpatched flaw in the web catalogue gives the attacker code execution as the unprivileged www account — a remote exploit, and by itself a limited win, because www cannot read borrower records. From that shell the attacker runs a setuid-root utility with a crafted argument and gets a root shell — a local exploit, and now every control on the box is theirs. The lesson: hardening that only defends the network perimeter leaves the second half of every intrusion unopposed, which is why minimising the number and size of setuid-root programs is a hardening step in its own right. They cannot be eliminated — logging in and binding to privileged ports genuinely need superuser rights — but many programs made setuid root for a programmer's convenience work perfectly as setgid to a suitable group.

The chroot jail, and its one famous hole

Some network services need only a small, fixed set of files — an FTP or file-drop service is the standard example. The chroot system call confines a process to a subtree by remapping / to some other directory: run the service under /srv/dropbox and its /etc/config is really /srv/dropbox/etc/config, while everything outside the subtree is not merely forbidden but not nameable. If the service is compromised, the attacker's reach is the jail.

There are three honest caveats and one of them is examinable. First, complexity: every library, device node and directory the service uses must be copied inside, and working out what that set is can be fiddly. Second, troubleshooting: even applications that explicitly support being chrooted can behave strangely inside one. Third — the one to memorise — a chrooted process running as root can break out of the jail with little difficulty. A jail is a confinement mechanism for an unprivileged service, not a security boundary against a privileged one. Say that in an exam and you have the mark; say "a chroot jail sandboxes the process" and you have said nothing that distinguishes it from a mechanism that actually holds.

The reference monitor: what a provably secure system would need

If we wanted assurance rather than confidence, what would the machine have to look like? The answer the trusted-systems tradition gives is the reference monitor: a controlling element in hardware and operating system that regulates every access by subjects to objects on the basis of their security parameters. It consults a security kernel database listing each subject's clearance and each object's classification, enforces the Bell–LaPadula rules from Module 7 (no read up, no write down), and writes security events — detected violations, authorised changes to the database — to an audit file.

Three properties are required of it, and each is hard for a different reason.

• Complete mediation. The rules are enforced on every access, not merely at, say, the moment a file is opened. The difficulty is cost: every reference to data in memory and on storage must be checked, and a pure software implementation is too slow, so a real solution must be at least partly in hardware.
• Isolation (tamperproofing). The monitor and its database must be shielded from unauthorised modification. The bar is absolute — however ingenious the attacker, there must be no route to altering the monitor's logic or the contents of the security kernel database.
• Verifiability. The monitor's correctness must be provable: it must be possible to demonstrate mathematically that it enforces the rules and achieves complete mediation and isolation. This is formidable for anything as complex as a general-purpose computer, which is the honest reason trusted systems never took the commercial market — that, and their cost and performance.

A system that can supply such a proof is called a trustworthy system. Note what "trusted" means here and does not mean elsewhere: it is a claim about demonstrated enforcement, not about anybody's feelings.

Common Criteria: what an evaluation is, and what a level says

The United States' TCSEC — the Orange Book, early 1980s, confidentiality-focused — was followed by national criteria elsewhere, and merging and extending those produced the Common Criteria in the late 1990s: ISO standards for specifying security requirements and defining evaluation criteria. The CC does three jobs across a product's life: during development it supplies sets of IT requirements of known validity from which to build a security specification; during evaluation it details how a product is evaluated against those requirements at a stated level of confidence; and in operation it defines a process for responding to newly discovered vulnerabilities and possibly re-evaluating.

The vocabulary is worth getting exact. The target of evaluation (TOE) is the part of the product or system actually under evaluation. Requirements come in two categories: functional requirements define the desired security behaviour, and assurance requirements are the basis for gaining confidence that the claimed measures are effective and correctly implemented. Both categories are organised in a four-level hierarchy: a class is a collection of requirements sharing a common focus; a family within a class groups requirements sharing an objective but differing in emphasis or rigour; a component is a specific set of requirements and is the smallest selectable unit; and a package is a reusable grouping of components known to be useful together — the standard illustration being the functional components a discretionary access control policy needs.

Assurance level is defined as a measure of confidence that a system's security features and architecture accurately mediate and enforce its security policy. There are seven Evaluation Assurance Levels, least to most rigorous: EAL 1 functionally tested, EAL 2 structurally tested, EAL 3 methodically tested and checked, EAL 4 methodically designed, tested and reviewed, EAL 5 semiformally designed and tested, EAL 6 semiformally verified design and tested, EAL 7 formally verified design and tested. Two structural facts belong with the list. EAL 1–4 correspond to grades of ordinary good commercial practice, and source code analysis is not required at all below EAL 4 — and even at EAL 4 only some of the code is examined. EAL 5–7 target products built by security specialists using methods chosen for security, with semiformal or formal models used to confirm the TOE really implements its security target; EAL 7 requires validating the correspondence among design, source code and object code — which is the only answer to a compiler-trust attack, in which a subverted compiler inserts a backdoor into the object code it emits while the source it was given stays clean, so that reviewing the source proves nothing at all.

Evaluation is normally regulated by a national agency — in the United States, NIST and NSA jointly run the Common Criteria Evaluation and Validation Scheme — and many countries recognise each other's evaluations, which matters given what one costs.

The TPM: assurance that shipped

Trusted computing came back as hardware. A Trusted Platform Module, standardised by the Trusted Computing Group, is a chip on the motherboard, in a smart card, or built into the processor, working with software approved to use it. It offers three services.

Authenticated boot brings the operating system up in stages, checking at each stage that the code being loaded is an approved version — often by verifying a digital signature — and keeping a tamper-evident log of the loading process, protected by a cryptographic hash so that the log cannot be quietly rewritten. When boot completes, the log states exactly which version of which components is running, and the trust boundary can then be extended upward to applications by the same approved-list check.

Certification turns that log into evidence for someone else: the TPM signs a formatted description of the configuration with its own private key. The recipient's confidence rests on two premises — the TPM is trustworthy, and only that TPM holds that private key. Freshness is handled by challenge: the requester sends a random number, the TPM appends it before signing, and the requester can therefore tell a current certificate from a replayed one. The scheme is hierarchical — the TPM certifies the hardware and OS configuration, and the certified OS can in turn certify applications.

Encryption is the service that makes the other two consequential. The TPM holds a master secret unique to the machine and derives from it a distinct encryption key for every possible configuration of that machine. Data encrypted in one configuration therefore cannot be decrypted in another — boot a different kernel, change the approved set, and the key that would unwrap the data is not the key the machine now derives. That single sentence is what makes sealed storage, measured boot and full-disk encryption tied to platform state all intelligible at once.