Overview
Validated Execution provides a way to verify the integrity of program and library objects at the time of execution. Such verification provides assurance that the executable has not been altered, either
accidentally or deliberately, since it was released by its publisher (which may be Sun, a third-party ISV, or the end customer).
There have been other attempts to solve this problem, such as Tripwire or bart, by comparing files against a manifest of known valid files. However, there is no protection against programs that are
modified after the comparison but before they are executed. Performing the verification at the time of use avoids the race condition inherent in solutions that periodically compare files against a known
reference.
Each executable file object is protected by a digital signature, which is constructed from a one-way hash of the file contents encrypted with a private RSA key known only to the publisher of the software. The corresponding public key can be used to decrypt the hash value and verify that it matches the file contents. Most ELF-format files in Solaris already contain an embedded digital signature; for those that do not and for non-ELF objects such as shell scripts, we provide a separate manifest listing the signatures for each file. This mechanism extends easily to allow third-party software vendors and end customers to create their own manifests of file signatures.
The general strategy employed is for entities that cause code to be loaded and executed, such as the kernel and run-time loader, to verify such code before execution. This establishes a chain of trust where each code component is validated by a previously validated component. To validate the earliest executing code in the system and initialize this process, we rely on a hardware component called a Trusted Platform Module (TPM). For systems without a TPM, all of the functionality described herein is still available, but the user must implicitly trust that the earliest code has not been modified.
This feature provides some degree of protection even against an attacker who is able to run processes with all privileges. We cannot protect in general against such a process, because it is able to alter any part of the file system or memory. However, the privileged process cannot alter the information stored in the TPM without knowledge of the TPM's owner password. Even if the running system is compromised, any alteration to the file system will be detected the next time the system is booted. Any executable files modified by the attacker will fail to start when the system reboots. Therefore, if an attacker gains privilege by exploiting a vulnerability, he must do so every time the system is booted rather than leaving behind a “back door” that can be used in the future to gain privileged access to the system.
Documentation
| Design Review, Round 2 |
| Design Review, Round 1 |
Current Status
| Milestone | Target | Complete | |
| Design Review, Round 1 | Q2CY08 | completed 4/2008 | |
| Design Review, Round 2 | Q3CY09 | scheduled 9/2009 |