Other Access Control Mechanisms

Other Access Control Mechanisms

Using ACLs is a useful method to protect resources, but there are other ways too. Three of the most common are .NET Framework roles, COM+ roles, IP restrictions, and SQL triggers and permissions. What makes these a little different from ACLs is that they are built into specific applications and ACLs are a critical core component of the operating system.

Roles are often used in financial or business applications to enforce policy. For example, an application might impose limits on the size of the transaction being processed, depending on whether the user making the request is a member of a specified role. Clerks might have authorization to process transactions that are less than a specified threshold, supervisors might have a higher limit, and vice presidents might have a still higher limit (or no limit at all). Role-based security can also be used when an application requires multiple approvals to complete an action. Such a case might be a purchasing system in which any employee can generate a purchase request but only a purchasing agent can convert that request into a purchase order that can be sent to a supplier.

The definition of roles is typically application-specific, as are the conditions under which one is willing to authorize specific actions.

Let's look at two programmatic role mechanisms supported by Windows: .NET Framework Roles and COM+ Roles.

.NET Framework Roles

.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.

More Info
A full explanation of .NET Framework roles is beyond the scope of this book. I recommend you refer to one of the books in the bibliography (such as Lippert or LaMacchia, Lange, et al) for more information.

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

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

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 (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).

IMPORTANT
If you want to enable potentially vulnerable Web-based functionality by default, consider setting an IP restriction that allows the code to execute from 127.0.0.1 only.

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 and Permissions

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.

A Medical Example

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:

Upon consultation, the doctor searches for, reads, and then updates the patient's medical information with the new findings, and an audit entry is written to the audit log. Nurses, charge nurses, and doctors can read a patient's medicine record, and charge nurses and doctors can update the patient's medicines. Any access to the patient's medicines is also audited. Only auditors can read the audit log, and doctors should never be auditors and therefore should never read from the log nor update the log.

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:

• Doctors (Read, Update)

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

• Doctors (Read, Update)

• Charge Nurses (Read, Update)

• Nurses (Read)

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

• Doctors (Deny Read, Deny Update)

• Auditors (All Access)

• Everyone (Write)

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('Northwindtraders\Auditors') 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.

An Important Note About Access Control Mechanisms

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.

IMPORTANT
When designing access control mechanisms, you need to be careful that the system cannot be circumvented by other means.

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!

IMPORTANT
You can provide access control to your application in many ways, including ACLs, SQL permissions, IP restrictions, and roles. Make sure you use the most appropriate technology for your application, and in some instances be prepared to layer the technologies for example, using both ACLs and IP restrictions in case one layer is compromised or incorrectly set up by the administrator.