Chapter 29. Writing a Semi-Trusted Application

for RuBoard

By Matthew Lyons

IN THIS CHAPTER

• Restrictions on Libraries That Can Be Called

• Making Permission Requests

• Protecting Data

• Being Careful About What Code Gets Executed

• Being Aware of Permissions at Runtime

Chapter 25, "Implementing a Secure Assembly," covered working with permissions in different forms and using strong names in your assemblies. These topics focus directly on interacting with the .NET Framework security system, which is most often done in fully trusted assemblies. Chapter 27, "Writing a Secure Web Site Using ASP.NET," and Chapter 28, "Writing a Secure Web Application in the .NET Development Platform," covered writing secure Web sites and Web applications with ASP.NET and the .NET Framework. This chapter covers security aspects of assemblies that are important for all .NET Framework assemblies, even those that are only semi-trusted by users.

NOTE

A semi-trusted application means that some program will be restricted in some way by the .NET Framework. For example, it might not be able to directly call into an unmanaged library, such as a Windows system DLL. Even though a semi-trusted application has restrictions, there are important details of security to remember when writing such an application.

There are several interesting aspects of security that apply to .NET applications. First, some class libraries may not be usable by semi-trusted applications due to protections from the .NET Framework. Second, you can make certain assurances about what permissions will be granted to your application. This is useful if you know your application must have a certain permission or should never be granted some other permission. Third, there are some important aspects to consider for sensitive data used by your application. For example, you will see how you can store data that cannot be accessed by other semi-trusted .NET applications. Fourth, it is beneficial to understand what happens with code execution in certain security- sensitive cases. If you don't understand how some .NET Framework features work, you can inadvertently expose security problems. Finally, code should be aware of permissions and security actions that happen. If you are oblivious to the fact that your code might be denied access to some resources, your applications may appear brittle and buggy to users.

NOTE

Microsoft has published a whitepaper on secure coding guidelines for the .NET Framework. Some information presented in that whitepaper is covered in this chapter. If you want to see all of Microsoft's suggestions for secure coding in the .NET Framework, you can find this whitepaper at http://msdn.microsoft.com/library/en-us/dnnetsec/html/seccodeguide.asp.

for RuBoard