This section has nothing to do with ACLs, but because this is a book about code security, I thought I’d round out the solution. The beginning of the solution is to write some code like this:

//Determine how much data to read.
DWORD cbBuff = 0;
if (RegQueryValueEx(hKey,
                    MY_VALUE,
                    NULL,
                    NULL,
                    NULL,
                    &cbBuff) == ERROR_SUCCESS) {

      BYTE *pbBuff = new BYTE[cbBuff];
      //Now read cbBuff bytes of data. 
      if (pbBuff && RegQueryValueEx(hKey,
                                    MY_VALUE,
                                    NULL,
                                    NULL,
                                    pbBuff,
                                    &cbBuff) == ERROR_SUCCESS) {
          //Cool!
          //We have read the data from the registry.

          //Use data

      }

      delete [] pbBuff;

This code still has a problem, but it’s a different issue. In this case, the code allocates memory dynamically, based on the size of the data, and then reads the data from the registry. If an attacker can write 10 MB of data in the registry, because of a weak ACL she has now forced your application to allocate 10 MB of memory. Imagine the consequences if you do this tens or hundreds of times in your code or if the code is in some kind of loop. Your application could allocate hundreds of megabytes of data because the attacker is forcing the application to read 10 MB per read. Before long the application has run out of memory and the computer has ground to a halt as it pages memory in and out of the swap file.

Personally, the fix I’d make is to use the following code:

BYTE bBuff[MAX_BUFF];
ZeroMemory(bBuff, MAX_BUFF);
HKEY hKey = NULL;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
                 "Software\Northwindtraders",
                 0,
                 KEY_READ,
                 &hKey) == ERROR_SUCCESS) {

      DWORD cbBuff = sizeof (bBuff);
      //Now read no more than MAX_BUFF bytes of data.
      if (RegQueryValueEx(hKey,
                          MY_VALUE,
                          NULL,
                          NULL,
                          bBuff,
                          &cbBuff) == ERROR_SUCCESS) {
            //Cool!
            //We have read the data from the registry.
      }
}

if (hKey) 
    RegCloseKey(hKey);

In this case, even if an attacker sets a large data value in the registry, the code will read up to MAX_BUFF bytes and no more. If there is more data, RegQueryValueEx will return an error, ERROR_MORE_DATA, indicating the buffer is not large enough to hold the data.

Once again, you can mitigate this threat by using good ACLs on the registry key in question, but you should still fix the code, just in case there’s a poor ACL or the administrator accidentally sets a poor ACL. That’s enough of a detour—let’s get back to ACLs.

Sometimes, when defining the access policy for resources, you’ll decide that some users should have no access to a resource. In that case, don’t be afraid to use a deny ACE.

Determining access control requirements is as simple as writing out the access control rules—again, based on the business rules—for the application and then looking for verbs and nouns in the requirements. Then you can determine which access control technologies are appropriate and how to configure the mechanisms to comply with the access control policy.

I remember the first time I used ACLs in some C++ code, and it was daunting. At that point I realized why so many people don’t bother creating good ACLs—it’s a complex task, requiring lots of error-prone code. If it makes you feel any better, the following example code is for Windows NT 4 and later. (The code for versions of Windows NT prior to version 4 would be even more complex, involving calls to malloc and AddAce!) The code shows how to create an ACL and, in turn, a security descriptor, which is then applied to a newly created directory. Note that the directory will already have an ACL inherited from the parent directory. This code overrides that ACL. Frankly, I never rely on default ACLs inherited from a parent container—you never know whether someone has set poor ACLs.

/*
  NT4ACL.cpp 
*/

#include <windows.h>
#include <stdio.h>
#include <aclapi.h>

PSID pEveryoneSID = NULL, pAdminSID = NULL, pNetworkSID  = NULL;
PACL pACL = NULL;
PSECURITY_DESCRIPTOR pSD = NULL;

//ACL will contain three ACEs:
//   Network (Deny Access)
//   Everyone (Read)
//   Admin (Full Control)
try { 
    const int NUM_ACES = 3;
    EXPLICIT_ACCESS ea[NUM_ACES];
    ZeroMemory(&ea, NUM_ACES * sizeof(EXPLICIT_ACCESS)) ;

    //Create a well- known SID for the Network logon group.
    SID_IDENTIFIER_AUTHORITY SIDAuthNT = SECURITY_NT_AUTHORITY;
    if (!AllocateAndInitializeSid(&SIDAuthNT, 1,
                                  SECURITY_NETWORK_RID,
                                  0, 0, 0, 0, 0, 0, 0,
                                  &pNetworkSID) ) 
        throw GetLastError();

    ea[0].grfAccessPermissions = GENERIC_ALL;
    ea[0].grfAccessMode = DENY_ACCESS;
    ea[0].grfInheritance= NO_INHERITANCE;
    ea[0].Trustee.TrusteeForm = TRUSTEE_IS_SID;
    ea[0].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
    ea[0].Trustee.ptstrName  = (LPTSTR) pNetworkSID;

    //Create a well-known SID for the Everyone group.
    SID_IDENTIFIER_AUTHORITY SIDAuthWorld =
                SECURITY_WORLD_SID_AUTHORITY;
    if (!AllocateAndInitializeSid(&SIDAuthWorld, 1,
                                  SECURITY_WORLD_RID,
                                  0, 0, 0, 0, 0, 0, 0,
                                  &pEveryoneSID) ) 
        throw GetLastError();

    ea[1].grfAccessPermissions = GENERIC_READ;
    ea[1].grfAccessMode = SET_ACCESS;
    ea[1].grfInheritance= NO_INHERITANCE;
    ea[1].Trustee.TrusteeForm = TRUSTEE_IS_SID;
    ea[1].Trustee.TrusteeType = TRUSTEE_IS_WELL_KNOWN_GROUP;
    ea[1].Trustee.ptstrName  = (LPTSTR) pEveryoneSID;

    //Create a SID for the BUILTINAdministrators group.
    if (!AllocateAndInitializeSid(&SIDAuthNT, 2,
                                  SECURITY_BUILTIN_DOMAIN_RID,
                                  DOMAIN_ALIAS_RID_ADMINS,
                                  0, 0, 0, 0, 0, 0,
                                  &pAdminSID) ) 
        throw GetLastError(); 

    ea[2].grfAccessPermissions = GENERIC_ALL;
    ea[2].grfAccessMode = SET_ACCESS;
    ea[2].grfInheritance= NO_INHERITANCE;
    ea[2].Trustee.TrusteeForm = TRUSTEE_IS_SID;
    ea[2].Trustee.TrusteeType = TRUSTEE_IS_GROUP;
    ea[2].Trustee.ptstrName  = (LPTSTR) pAdminSID;

    //Create a new ACL with the three ACEs.
    if (ERROR_SUCCESS != SetEntriesInAcl(NUM_ACES, 
        ea, 
        NULL, 
        &pACL)) 
        throw GetLastError();

    //Initialize a security descriptor.  
    pSD = (PSECURITY_DESCRIPTOR) LocalAlloc(LPTR, 
                               SECURITY_DESCRIPTOR_MIN_LENGTH); 
    if (pSD == NULL) 
        throw GetLastError();

    if (!InitializeSecurityDescriptor(pSD, 
                               SECURITY_DESCRIPTOR_REVISION))
        throw GetLastError(); 

    // Add the ACL to the security descriptor. 
    if (!SetSecurityDescriptorDacl(pSD, 
                                   TRUE,     //  fDaclPresent flag   
                                   pACL, 
                                   FALSE)) {  
        throw GetLastError(); 
    } else {
        SECURITY_ATTRIBUTES sa;
        sa.nLength = sizeof(SECURITY_ATTRIBUTES);
        sa.bInheritHandle = FALSE;
        sa.lpSecurityDescriptor = pSD;

        if (!CreateDirectory("C:\Program Files\MyStuff", &sa)) 
            throw GetLastError();
    } // End try
} catch(...) {
    // Error condition
}

if (pSD) 
    LocalFree(pSD);

if (pACL)
    LocalFree(pACL);

//  Call FreeSID for each SID allocated by AllocateAndInitializeSID.
if (pEveryoneSID) 
    FreeSid(pEveryoneSID);

if (pNetworkSID)
    FreeSid(pNetworkSID);

if (pAdminSID) 
    FreeSid(pAdminSID);

This sample code is also available in the companion content in the folder Secureco2Chapter06. As you can see, the code is not trivial, so let me explain what’s going on. First you need to understand that you do not apply an ACL directly to an object—you apply a security descriptor (SD). The SD is encapsulated in a SECURITY_ATTRIBUTES structure, which contains a field that determines whether the SD is inherited by the process. A security descriptor includes information that specifies the following components of an object’s security:

If any of the components of a security descriptor are missing, defaults are used. For example, the default owner is the same as the identity of the process calling the function or the Builtin Administrators group if the caller is a member of that group. In the preceding example, only the DACL is set. As mentioned, the security descriptor contains a DACL, and this is made up of one or more EXPLICIT_ACCESS structures. Each EXPLICIT_ACCESS structure represents one ACE. Finally, each EXPLICIT_ACCESS structure contains a SID and which permissions that SID has when attempting to use the object. The EXPLICIT_ACCESS structure also contains other details, such as whether the ACE is to be inherited. The process of creating an ACL is also illustrated in Figure 6-1.

Two other APIs exist for setting ACLs on files: SetFileSecurity and SetNamedSecurityInfo. SetFileSecurity is available in all versions of Windows NT, and SetNamedSecurityInfo is available in Windows NT 4 and later.

Figure 6-1. The process of creating an ACL.

If your application runs on Windows 2000 or later, there is some relief from such code in the form of the Security Descriptor Definition Language, covered next.

Recognizing that many people did not understand the ACL and security descriptor functions in Windows NT 4, the Windows 2000 security engineering team added a textual ACL and security descriptor representation called the Security Descriptor Definition Language (SDDL). Essentially, SIDs and ACEs are represented in SDDL through the use of well-defined letters.

The following example code creates a directory named c:MyDir and sets the following ACE:

/*
  SDDLACL.cpp
*/

#define _WIN32_WINNT 0x0500

#include <windows.h>
#include <sddl.h>

void main() {
    SECURITY_ATTRIBUTES sa;
    sa.nLength = sizeof(SECURITY_ATTRIBUTES);
    sa.bInheritHandle = FALSE;
    char *szSD = "D:P"                      //DACL
         "(D;OICI;GA;;;BG)"         //Deny Guests
         "(A;OICI;GA;;;SY)"         //Allow SYSTEM Full Control
         "(A;OICI;GA;;;BA)"         //Allow Admins Full Control
         "(A;OICI;GRGWGX;;;IU)";    //Allow Interactive Users RWX

    if (ConvertStringSecurityDescriptorToSecurityDescriptor(
        szSD,
        SDDL_REVISION_1, 
        &(sa.lpSecurityDescriptor), 
        NULL)) {

        if (!CreateDirectory("C:\MyDir", &sa )) {
            DWORD err = GetLastError();
        }

        LocalFree(sa.lpSecurityDescriptor);
   } 
}

This code is significantly shorter and easier to understand than that in the Windows NT 4 example. Needing some explanation, however, is the SDDL string in the szSD string. The variable szSD contains an SDDL representation of the ACL. Table 6-2 outlines what the string means. You can also find this sample code in the companion content in the folder Secureco2Chapter06.

Figure 6-2 shows the general layout of the SDDL string in the previous sample code.

Figure 6-2. The sample SDDL string explained.

No doubt you’ll need to use other User accounts and Builtin accounts, so Table 6-3 presents a partial list of the well-known SIDs in Windows 2000 and later.

The advantage of SDDL is that it can be persisted into configuration files or XML files. For example, SDDL is used by the Security Configuration Editor .inf files to represent ACLs for the registry and NTFS.

The ATL is a set of template-based C++ classes included with Microsoft Visual Studio 6 and Visual Studio .NET. A new set of security-related ATL classes have been added to Visual Studio .NET to make managing common Windows security tasks, including ACLs and security descriptors, much easier. The following sample code, created using Visual Studio .NET, creates a directory and assigns an ACL to the directory. The ACL is

/*
  ATLACL.cpp 
*/

#include <atlsecurity.h>
#include <iostream>

using namespace std;

void main(){

    try {
        //The user accounts
        CSid sidBlake("Northwindtraders\blake");
        CSid sidAdmin = Sids::Admins();
        CSid sidGuests = Sids::Guests();

        //Create the ACL, and populate with ACEs.
        //Note the deny ACE is placed before the allow ACEs.
        CDacl dacl;
        dacl.AddDeniedAce(sidGuests, GENERIC_ALL);
        dacl.AddAllowedAce(sidBlake, GENERIC_READ);
        dacl.AddAllowedAce(sidAdmin, GENERIC_ALL);

        //Create the security descriptor and attributes.
        CSecurityDesc sd;
        sd.SetDacl(dacl);
        CSecurityAttributes sa(sd);

        //Create the directory with the security attributes.
        if (CreateDirectory("c:\MyTestDir", &sa))
            cout << "Directory created!" << endl;

    } catch(CAtlException e) {
        cerr << "Error, application failed with error " 
             << hex << (HRESULT)e << endl;
    }
}

In my opinion, this code is much easier to understand than both the Windows NT 4 and Windows 2000 SDDL versions. It’s easier than the Windows NT 4 code because it’s less verbose, and it’s easier than the Windows 2000 SDDL code because it’s less cryptic. This sample code is also available in the companion content in the folder Secureco2Chapter06.

Now that I’ve discussed how to define good ACLs for your application and methods for creating them, let’s look at some common mistakes made when creating ACLs.

Here’s another insidious aspect of NULL DACLs: if a valid user does indeed change a NULL DACL to Everyone (Deny Access), chances are good that nothing is logged in the Windows event log to indicate this malicious act because the chances are also good that you have no audit ACE (an SACL) on the object either!

You should be wary of three other dangerous ACE types: Everyone (WRITE_DAC), Everyone (WRITE_OWNER), and directory ACLs, which allow anyone to add new executables.

I can think of no reason to create an object with a NULL DACL, other than the case in which it simply doesn’t matter if the object is compromised. I saw an example of this once where a dialog box would pop up to tell the user a joke. It used a mutex, with a NULL DACL to "protect" it, to make sure that multiple versions of the application did not put multiple instances of the dialog box on the screen at once. If an attacker placed a deny ACE on the object, the user would not see any jokes—not a major problem!

At an absolute minimum, you should create an ACL that does not allow all users to

The access mask will vary from object to object. For example, for a registry key, the mask will be the following:

DWORD dwFlags = KEY_ALL_ACCESS 
                & ~WRITE_DAC 
                & ~WRITE_OWNER
                & ~DELETE;

For a file or directory, it will be like this:

DWORD dwFlags = FILE_ALL_ACCESS 
                & ~WRITE_DAC 
                & ~WRITE_OWNER
                & ~DELETE
                & ~FILE_DELETE_CHILD 

.NET Framework role-based security supports authorization by making information about the principal, which is constructed from an associated identity, available to the current thread. The identity (and the principal it helps to define) can be either based on a Windows account or be a custom identity unrelated to a Windows account. .NET Framework applications can make authorization decisions based on the principal’s identity or role membership, or both. A role is a named set of principals that have the same privileges with respect to security (such as a teller or a manager). A principal can be a member of one or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action.

To provide ease of use and consistency with code access security, .NET Framework role-based security provides PrincipalPermission objects that enable the common language runtime to perform authorization in a way that is similar to code access security checks. The PrincipalPermission class represents the identity or role that the principal must match and is compatible with both declarative and imperative security checks. You can also access a principal’s identity information directly and perform role and identity checks in your code when needed.

The following code snippet shows how you can apply .NET Framework roles in a Web service or a Web page:

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);

if ( wp.IsInRole("Managers")) {

  //User is authorized to perform manager-specific functionality

}

You can perform a similar task on the current thread:

WindowsPrincipal principal = 
    (Thread.CurrentPrincipal as WindowsPrincipal);
if (principal.IsInRole("Administrator")) {
        //user is an admin
}

Note that WindowsPrincipal.IsInRole verifies that the caller is a member of a Windows group, and GenericPrincipal.IsInRole determines whether the caller is a member of a generic role, where the role population may come from a database or a configuration file. The GenericPrincipal constructor allows you to define the principal’s role membership. The following C# example outlines the process.

GenericIdentity id = new GenericIdentity("Blake");
//Role list could come from an XML file or database
String[] roles = {"Manager", "Teller"}; 
GenericPrincipal principal = new GenericPrincipal(id, roles);

COM+ roles are somewhat similar to Windows groups, but rather than being defined and populated by a network administrator, they are defined by the application designer at development time and populated by an application administrator at deployment time. This allows for great flexibility because the network group membership and the application role membership are related yet independent, which allows for application design flexibility.

Roles are enforced by COM+ at the application level by using the Component Services management tool, or they can be enforced programmatically using the IsCallerInRole method. The following Visual Basic code shows how the method is used:

‘ Get the security call context.
Dim fAllowed As Boolean
Dim objCallCtx As SecurityCallContext
Set objCallCtx = GetSecurityCallContext()

‘ Perform the role check.
fAllowed = objCallCtx.IsCallerInRole("Doctor")
If (fAllowed) Then
    ’ Act according to the result. 
End If

Unlike ACLs, which protect resources, roles protect code. It is the code that then accesses the resource being protected. However, role-enforcing code can combine other business rules with the role logic to determine access. The following code highlights this.

fIsDoctor = objCallCtx.IsCallerInRole("Doctor")
fIsOnDuty = IsCurrentlyOnDuty(szPersonID)
If (fIsDoctor And fIsOnDuty) Then
    ’ Perform tasks that require an on-duty doctor.
End If

The combination of business logic and role-based authorization is a powerful and useful capability.

IP restrictions are a component of most Web servers, including IIS. Using IP restrictions, a developer or administrator can restrict access to parts of a Web site to specific IP addresses (for example, 192.168.19.23), subnets (192.168.19.0/24), DNS names (http://www.microsoft.com), and domain names (*.microsoft.com). If you’re building Web-based applications, don’t rule out using IP restrictions. For example, you might include some form of administration functionality. One way of restricting who can use the administration tools is to place an IP restriction limiting the usage to the IP addresses of certain administration machines.

If you find your analysis of your business requirements and access rights includes wording like "accessible only at the local machine" or "deny access to all users and computers in the accounting.northwindtraders.com domain," you might need to consider using IP restrictions.

IP restrictions can also be useful if you include functionality that you want enabled by default but don’t want attackers using. You can achieve this by setting an IP restriction on the virtual directory you create to allow your code to execute only at the local machine (127.0.0.1).

The following sample VBScript code shows how to set IP restrictions on the Samples virtual directory on the default Web server such that only localhost (that is, the reserved address 127.0.0.1) can access it:

‘ Get the IP Settings.
Dim oVDir
Dim oIP
Set oVDir = GetObject("IIS://localhost/W3SVC/1/Samples")
Set oIP = oVDir.IPSecurity

‘ Set the IP grant list to 127.0.0.1.
Dim IPList(1)
IPList(1) = "127.0.0.1"
oIP.IPGrant = IPList

‘ Do not grant access by default.
oIP.GrantByDefault = False

‘ Write the information back to 
‘ Internet Information Services, and clean up. 
oVDir.IPSecurity = oIP
oVDir.SetInfo
Set oIP = Nothing
Set oVDir = Nothing

SQL Server triggers allow the developer to place arbitrarily complex access rules on SQL tables. A trigger is called automatically by the SQL engine when data in the table is either added, deleted, or modified. Note that triggers are not used when data is read. This can be problematic, as you might create an application with some access control logic using one or more triggers to access control logic in other parts of the database, such as permissions. The triggers will not be executed if a read operation is attempted.

Permissions are to SQL Server what ACLs are to Windows and are in the simple form "subject doing something to object." Examples include "Blake can read from the Accounts table" and "Auditors can Read, Write, and Delete from the AuditLog table." All objects can be secured in SQL Server by using permissions.

Let’s look at an example that uses other access control techniques. This is a simplified scenario from a medical application. Interviews with the client reveal the following scenario when a doctor updates a patient’s medical records:

It is determined in this case that search is the same as read.

From this we derive the following access policy for the patient data:

The following is the access policy for the patient’s medicine data:

And the following access policy is derived for the audit log:

In this example, charge nurses, doctors, and auditors can be Windows groups or SQL Server or COM+ roles. (Note that other medical scenarios might change the access permissions.) It’s important to realize that the resources should not be implemented as resources that can be ACLed. A good example is the data held in SQL Server—in this case, all patient data is held in the database, as is the audit log.

The nice thing about this scenario-based approach is that the access control policy is implementation-independent. For example, you might determine that a trigger on a SQL Server table determines the implementation of that policy. The following is an example of a trigger that is fired when a user attempts to update or delete data in an audit log table. If that user is not in the Auditor’s group, the transaction is rolled back (that is, the transaction does not occur):

create trigger checkaudit on tblAuditLog
for update, delete
as 
begin
if not is_member(‘NorthwindtradersAuditors’)
    rollback tran
end

Note that the trigger is not called when anyone inserts data into the audit log, and according to the business rules anyone can write to the log. There is a flaw, however: anyone can read the data from the audit log, and triggers are not used when reading data. In this case, you’d be wise to apply a permission to the table also, such as "public can only write to the audit log." Public is the equivalent of the Everyone group in Windows. Because audit logs are so sensitive, it’s worthwhile having two levels of protection. Remember: defense in depth! In this case, the permissions on the table and the trigger acting as a backstop in case an administrator accidentally removes the permissions from the audit log table provide defense in depth.

Access control mechanisms that are not built into the operating system might lead to vulnerabilities in the application. Allow me to explain. Take a look at Figure 6-3, which shows a system protecting resources with IP restrictions implemented in a Web server.

Figure 6-3. A system protecting resources with IP restrictions.

The problem in this example is that the system also has file access capabilities enabled. If the attacker can use the file services directly, he might be able to bypass the IP restrictions because IP restrictions, a Web server feature, don’t exist in the file access services.

Here’s an example. While I worked on the IIS team, another team created a Web site to invite their entire team to a private screening of Star Wars, Episode One: The Phantom Menace. We in IIS believed we should be invited too, so a small group of us decided to invite ourselves! As we probed the Web server, we noted that the logic determining whether a user was on the other team was held in the Web site’s pages. A little more work showed the team had a file share (an SMB share) to the Web pages. We connected to the file share, and sure enough the ACLs on the Web site files were weak. So we changed the site to invite IIS to the movie also!