Considering Access Problems with the Win32 API

The structure and setup of the Win32 API make it possible to create security holes without realizing it. In some cases, a perfectly good setup will fail because you didn’t test all of the user categories completely. Other situations may cause a failure when you don’t understand a nuance of Windows security. Too many people accessing the same security information and making changes independently of each other can cause problems too. The following sections discuss potential access problems for developers working with the Win32 API.

Using the Run As Windows Feature

This section isn’t actually about an access problem—it’s an access solution. When you want to test the security of an application, you have several choices. The first choice is to log out and back on as the user you want to check. However, this can prove time consuming if you need to test several user types.

The second choice is to send a copy of the beta software to a testing group and let them check it. Unfortunately, this technique isn’t very practical if you’re an independent developer or if the change you want to test is small enough that you don’t want to bother the testing group. Besides, if you perform the test yourself, you can ensure that you test all of the security features.

The third option is actually the most efficient. After you compile the program, right-click the executable and select Run As from the context menu. You’ll see a Run As dialog box. Choose The Following User option. Select the user from the drop-down list and type their password. The application starts using that user’s credentials. Using this technique can save considerable time because you can start the application with a test user’s credentials without logging in or out of the system.

Understanding Resources Both Granted and Denied

Once you know how Windows evaluates the ACEs in the DACL, you’ll discover a few problem areas—problems that the Windows utilities address automatically but your code won’t. These potential security issues are the reasons you might want to consider just reading the security information using application code and use utilities as needed to modify the security information. Unfortunately, it’s not always possible to follow this advice, so this section discusses the access pitfalls.

Order is an important consideration when working with Windows security because Windows uses a very basic method for determining how to evaluate the security elements. You’ll need to program around these problems to derive the same result found in the various Windows utilities. The SACL has the same problem, but it only affects auditing, so the effect is less severe from the system security standpoint.

Windows evaluates the ACEs in an ACL in the order in which they appear. At first, this might not seem like a very big deal. However, it could become a problem in some situations. For example, what if you want to revoke all of a user’s rights to one resource, but his or her list of ACEs includes membership in a group that allows access to that resource? If you place the access-allowed ACE before the access-denied ACE in the list, the user would get access to the resource. When the access-denied ACE appears first, the user loses access to the resource. The ACEs are the same—only their order is different. The bottom line is that you should place all your access-denied ACEs in the list first, to prevent any potential breach in security.

Also, use care in the ordering of group SIDs. Rights that a user acquires from different groups are cumulative. This means a user who appears in two groups, one that has access to a file and another that doesn’t, will have access to the file if the group granting the right appears first on the list. In addition, if one ACE grants read rights and another write rights to a file, and the user is asking for read and write rights, Windows will grant the request.

Obviously, you could spend all your time trying to figure out the best arrangement of groups. As the number of groups and individual rights that a user possesses increases, the potential for an unintended security breach does as well. That’s why it’s important to create groups carefully and limit a user’s individual rights. It’s also essential that you actually test various user scenarios using impersonation—see the “Using the Run As Windows Feature” section for details.