Understanding Code-Access Security

Team Fly

Page 125

mobile code—networked, or web-based applications—can of course be more complex. You often don't know who's on the other end of an Internet connection, or what hard drive is being used as the server, or, most important, what methods are being executed against your local hard drive or network.

However, .NET insists that in all cases, both role-based and code-based security settings must be satisfied for a particular action to take place. For example, if you attempt to load a file into a .NET TextBox, several security settings are triggered and all must be satisfied before the file is loaded. The .NET application's identity is checked; is it from a trusted source? Does this application have permission (from code-access security settings) to read this file? And does this user have permission from the Windows security settings to read this directory and this particular file? If any of these questions are answered No, the file doesn't get into the TextBox.

This last question—Windows permissions—becomes impossible to answer when you're consuming a remote Web service, for example. Of course the author of the Web service response doesn't have permission to access your Windows machine at any level. That foreign person is unknown to your installation of Windows and isn't a member of any group known to your administrator.

One solution to communication with strangers is to keep them in the lobby and talk to them through an intercom, or if you're running a gas station, encase your clerks inside bullet-proof Plexiglas. In other words, fix it so you can communicate with strangers, but don't let them get next to you physically. Don't let them completely in. This, in essence, is the idea of ''partial trust," the notion that you keep the stranger at a distance—close enough to talk to, but beyond the range of a knife or bullet.

Similarly, you can communicate with unknown Internet servers and other strangers by partially trusting them—letting them near, but not actually in, your system.

The CAS system has been developed to permit you to consume mobile executable code securely within .NET (or indeed other contexts). In fact, unless you specify otherwise, any executable coming in from the Internet is by default executed within this "partially trusted" context. Foreign, unrecognized executables are kept in the lobby by security, so to speak.

One meaning of the term mobile code is distributed code (code not local to an application on your machine, but rather coming into your machine from the Internet, an intranet, or modules distributed on separate servers). In other words, it's alien code that resides outside the local environment. As is usually the case, however, new computer terminology forks rapidly into more than a single meaning. Mobile is also being used these days to describe portable devices, specifically PDAs and cell phones (see Chapter 22 for details on programming for these mobile devices).

Scripting was one effort in the past to permit harmless mobile code to execute safely on your machine. The idea was: We'll take a language like VB and strip it of any methods that can manipulate the hard drive, the Registry, or other sensitive resources. Then, with this new "VBScript," people can trust that it's unable to do damage. Alas, this solution, like verification and other initiatives, was only partially successful. After all, hackers have learned how to embed executables in strings, and other techniques that make scripts potentially just as damaging as traditional executables.

Verification slows things down. One type of authentication surprises users with a dialog box asking them if they trust this Authenticoded site. This not only halts execution, it throws the responsibility for virus attacks onto the user—many of whom are not equipped to respond usefully to the

Team Fly