Securing Controls and Components


The security information contained in the “Working with the DACL” and “Working with the SACL” sections of this chapter apply to just about any kind of object you can imagine. The fact that the examples rely on a file doesn’t make much of a difference. However, components and controls do require some changes in the way you handle certain security features.

The first consideration is the need to use the Win32 API at all. You can make a good case for using the Win32 API when an application uses a component as an in-process server. Because the client and the component share the same memory and resources, it’s important to coordinate their security efforts as well. However, when working with an out-of-process server, it’s easier to use security that suits the component, rather than the host application because the application and component might not even appear on the same machine. Always provide control security that works with the client. In some cases, this might mean providing separate versions of the control for managed and unmanaged code are needed if you can’t create a security solution that works properly for both environments.

Another consideration is the caller. The application-oriented examples in the previous sections of the chapter assumed that the current process is making all of the changes and that the current process is trustworthy. When designing component and control security of the Win32 API environment, you must consider that the current process isn’t likely to make the changes—the calling application will. In addition, because you know nothing about the calling application, it isn’t safe to assume that it’s trustworthy.

You also have to consider the communication environment. For example, when working in a LAN environment, you may need to use DCOM to maintain compatibility with older applications. The “Working with DCOM” section of Chapter 8 shows how to code an example to use DCOM properly. See the “Working with Remote Unmanaged Components” section of this chapter for a discussion of how to configure a component once you create secure code for it. The bottom line is that transparent communication is essential.

A final consideration for the Win32 API environment is that you don’t have as many choices as you do when working with .NET security. The emphasis is on what the caller can do. In addition, you can’t consider context as part of the security solution—a user who calls from the Internet will have the same rights as when calling from a local machine. It’s essential to consider these factors when developing your component and provide some form of administrator-level control over how the component resolves security issues. Make sure you also use conservative settings for the component setup.




.Net Development Security Solutions
.NET Development Security Solutions
ISBN: 0782142664
EAN: 2147483647
Year: 2003
Pages: 168

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net