Professional C# 2005

Chapter 16. .NET Security

You're sitting at your machine and you click a button on an application you're using. Behind the scenes, your application responds to the fact that you are attempting to use a feature for which it does not have the relevant module. It connects to the Internet, downloads the module into the Download Assembly Cache, and begins executing—all without prompting you.

This kind of behind-the-scenes upgrade functionality is already used with many .NET applications, but there is a concern here over the security implications relating to what is called mobile code. In clear terms, what evidence do you actually have that you can trust the code your computer is downloading? How do you know that the module you requested is, in fact, the one that you are receiving? What does the CLR do behind the scenes to ensure, for example, that a control on a Web site is not reading your private e-mails?

.NET enforces a security policy around assemblies. It uses the evidence it has about them—where they are from or by whom they are published—to group the assemblies with similar characteristics. For example, the runtime places all code from the local intranet into a specific group. It then uses the security policy (normally defined by a system administrator using the Code Access Security Policy Tool (caspol.exe) command-line utility, or the Microsoft Management Console) to decide what permissions the code should be granted at a very granular level. What do you have to do to enable security ...