Architectures for Practical Security

摘要

Few of the system architectures for security proposed for the past four decades (e.g., fine-grain domains of protection, virtual machines) have made a significant difference on client-side security. In this presentation, I examine some of the reasons for this and some of the lessons learned to date. Focus on client-side security is warranted primarily because it is substantially more difficult to achieve than server security in practice, since clients interact with human users directly. I argue that system and application partitioning to meet user security needs is now feasible, and that special focus must be placed on how to design and implement trustworthy communication, not merely secure channels, between system partitions. Two forms of partitioning system and network components are described. The first, which is inspired by Lampson's Red/Green separation idea [1], partitions system resources instead of "virtualizing" them, and switches between partitions only under (human) user control exercised via a trusted path. Neither operating systems nor applications can escape their partition or transfer control to other partitions behind the user's back [2] as a consequence of malware or insider attacks. Trustworthy communication among system and network partitions, which can be established only via network communication, goes beyond firewalls, guards and filters. The extent to which one partition accepts input from or outputs to another depends on the accountability of, and trust established with, the input provider and output receiver. It also depends on input-rate throttling and output propagation control, which often require establishing some degree of control over remote communication end points. The second form of partitioning separates programmer-selected, security-sensitive code blocks from untrusted operating system code, applications and devices, and provides strong guarantees of data secrecy and integrity, as well as execution integrity, to an external entity via attestation [3]. Again, the key criterion for the separation and isolation of sensitive code partitions from untrusted code is the ability to establish trustworthy communication between security-sensitive and untrusted code; e.g., the security-sensitive code accepts only input whose validity it can verify in its own partition, and provides output only in areas that are legitimately accessible to untrusted code. The design of security-sensitive code partitions relies on source code analysis for modularity, where module input/output control -- not just security-policy isolation and code size minimization -- is a property of interest. Several applications of security-sensitive code isolation are illustrated.