Chapter 9: Security

Never underestimate the time, expense, and effort an opponent will expend to break a code.
— Robert Morris

Overview

Writing secure code is extremely important in today's highly connected world. With dynamic features that load and execute code from the Internet, a never-ending supply of third-party components, and a generally increasingly synthesized execution environment, seldom is a piece of software run in perfect isolation. As we move further in this direction, you can never be too paranoid about rogue code gaining the ability to do things you didn't want it to.

As an example of one such attack vector you might be concerned above, Internet Explorer can be used to host managed code controls on a web page. Clearly if that code isn't run with some sort of security isolation, it would be able to do some nasty things to the end user. (Like format the disk, for example.) Similarly, you might be an ISV writing a sophisticated and complex application that hosts extensible add-ins. If those add-ins were able to compromise the integrity of your host application, your own customers might become the target of nasty security attacks. This could cause a quick outbound deluge of trust in you as a software vendor (and probably market share). Code access security (CAS) enables the style of sandboxing necessary for these types of programs.

Security is, of course, everybody's responsibility. But your interest in it is likely to vary depending on what type of software you are writing. For example, an ISV shipping a host application as described above is apt to be significantly more concerned when compared to a small-business IT shop developing a tiny application for 10 users. A vendor of a reusable Framework will want to ensure components work well inside a sandbox, so that they can be used inside of that ISV's sandboxed application, for example. But if you're an enterprise developer, your focus will likely shift from code access security to other topics like accessing Windows authentication and role-based security information, and figuring out how to integrate that information across the network. My hope is that this chapter has enough of each of those topics to be of interest to a broad range of software architects and developers.

We'll begin the chapter with a tour of the CLR's native integral security sandboxing mechanism, CAS. CAS employs a different principal than most developers are accustomed to, namely that it governs permissions based on the identity of software and not necessarily its user. Notice the key shift here: it's not the person running the software that needs to be trusted; it's the piece of software. Managed code running in a sandboxed environment (called partially trusted code) is monitored by the runtime to ensure that any privileged operations it attempts are carefully monitored. Such actions are permitted or denied based on configuration.

We'll also take a look at how to access more traditional authentication and authorization information in this chapter, and how you might use it to implement or work with role-based security systems. We'll also take a look at how Windows Access Control List (ACL) security is now (as of 2.0) exposed in a richer way throughout many of the Base Class Libraries. This affects various IO and Windows kernel object managed APIs.