Key concepts in this chapter are:
Handling security-related code-access violations
Running applications in different security zones
Modifying code to work within the bounds of different security zones
Using isolated storage in place of traditional file I/O
What is code-access security—or CAS, as it’s affectionately called? Code-access security is designed to protect applications and components in shared environments—such as your local network or the Internet—from the following risks:
Inadvertently or intentionally damaging or destroying sensitive data
Crippling the computer on which the code is running by consuming all available resources, such as all available memory or disk space—an event known as a denial of service (DoS) attack
Allowing calling code or attackers to intentionally or unintentionally elevate their privileges to perform actions such as viewing sensitive user information stored on the computer where the code is running—an event known as a luring attack
Take for example a chart component that shows stock price history embedded within a stock-trading Web page. Do you want to give free reign to the component to do whatever it wants to your computer, such as delete arbitrary files? Probably not. You want to be assured that the component can perform only safe activities such as show a graph of stock prices, and that it won’t delete your personal files or transfer personal information back to the Web server as it shows you a cool graph. Moreover, you want to be assured that if a component attempts to perform an unsafe action the code-access security system will step in and prevent the action from happening. In addition, you want to be assured an untrusted application that calls a method on your component can’t force the component to do bad things—things the calling application itself is not allowed to perform. For example, you don’t want an application calling the SaveChart method of your Chart control passing the path and filename of an existing system file or personal file, which gets overwritten (destroyed) by the call. The code-access security system should detect that an untrusted caller is attempting to call a method that it has no business calling, issue a security exception, and prevent the action from taking place.
The purpose of code-access security is to permit only actions considered to be safe—or put another way, to prevent actions considered to be unsafe. How does code-access security determine which actions are safe or unsafe? And how does code-access security prevent harmful code from executing?
The .NET code-access security system assigns your application or component permissions such as file-access, user-interface, and network permissions as the basis of determining what safe or unsafe operations your application is allowed to perform. The collective set of permissions assigned to your application is based on the level of trust assigned to your application. Applications installed—including applications installed by the means of a setup program from the Internet—and run on your computer are considered to be highly trusted, so they’re given all available permissions. By contrast, components loaded and run from the Internet are considered highly untrusted and are given few permissions.
The .NET code-access security system uses a sophisticated means of determining what permissions your Microsoft Visual Basic .NET application or component is granted. The location from which the application is run is a major factor in determining what permissions your application is granted. For example, if the chart component is loaded by an application that you run on your local computer, the chart component is given the permission to delete files. However, if the chart component is run directly from the Internet (actually, components or applications run directly from the Internet are first downloaded to a special Internet download cache on your computer and executed), it’s denied the permission to delete files. The location from which an application is run is a piece of evidence the code-access security system uses to determine what permissions to grant the application. Chapter 10 demonstrates how you can supply other types of evidence, such as the name of your application, to the code-access security system so that it will grant your application custom permissions.
Note
Be wary of applications and components you are asked to install and run on your computer (as presented in Chapter 10). These applications typically are accompanied by a dialog box that warns you about running an application you have downloaded from the Internet (or opened in e-mail), and you are given the choice to save the application or execute it. Just because applications or components that run on your computer are highly trusted and considered safe by the .NET code-access security system does not mean that the component will behave as advertised or is somehow verified to not do bad things. If you download and install an application or component from the Internet—including .NET applications and components—the code-access security model is not aware of this fact. The application or component will run with full trust and will be able to perform any action that you can perform on the computer. If you are logged in as the administrator, the component will have free reign over your system. This is why it is important that you log on as a regular user and not as an administrator, as presented in Chapter 11.