Code-Access Security Versus Role-Based Security

The immediate and obvious example of a computer security system is the one most of us encounter the first thing in the morning: the login prompt. The purpose of the login prompt is to authenticate you, to verify your identity somehow. After your identity has been determined, you are authorized to perform certain tasks: delete this file, run that application, and so on.

Determining identity is a hard problem, and many strategies exist for doing so. Each strategy, however, is based on consuming some evidence and making a decision based on it. Evidence might be based on the ability to produce a secret (such as a password), possession of an object (such as a smart card), biometrics (such as thumbprints or retinal scans), and so on.

After you have been authenticated, the security system knows of which groups you are a member and can enforce policies based on identity and group membership. A policy, for example, might be "only members of the Administrators group can modify registry keys in the Local Machine hive." Policies are implemented by access control lists and other mechanisms in the operating system, and administered by various application programming interfaces (APIs).

The system just described is a role-based security system. In a role-based security system, the fundamental question is "Who is running the code?" After that has been determined, the code runs with all the privileges and restrictions of the user. A fundamental presumption of role-based security systems is that users run some code because they know what it does and want it to succeed. When you run format.exe, the operating system presumes that you really do want to format your hard disk and checks to ensure that you have permission to do so.

But sometimes role-based security is not enough. Consider a Web page that runs a script that tries to format the hard disk. In that case, whether the user who started the Web browser has the right to destroy the disk in question is of secondary importance. What is more relevant is whether the user actually intended the Web page to format the hard disk! The fundamental presumption of role-based security no longer applies; in a world with mobile code that sits behind Web pages, e-mails, and documents, the user does not necessarily know what the code is doing and may not want it to succeed.

Internet Explorer, therefore, implements a code-access security system. A code-access security system consumes evidence not about the user running the code, but about the code itself. Where did it come from? Who wrote it? What is the user's trust relationship with the Web site? The browser can then enforce policies such as "Web pages in the Untrusted Sites zone are not allowed to run scripts at all," and users and administrators can set policies accordingly.

The .NET security system implements both role-based and code-access security systems, but for our purposes this discussion examines only the code-access security system. Customized documents are much more like Web pages, where the user might not know exactly what the customization is doing.