1. CONSIDERING BASIC NT SECURITY FEATURE CHANGES
Windows 7 has a number of new security features. Some
are internal. You won't use the following features directly, but they
do affect the way in which your application executes.
Kernel patch protection
Service hardening
Data execution prevention
Address space layout randomization
Mandatory integrity levels
These features change the way Windows 7 executes your
application and the environment in which the application executes. In
some cases, you may need to consider how these features work when
writing your application, but managed application code developers, such
as those who use C#, can probably forget these features even exist
except to realize that they work in the background to secure the
application environment.
Microsoft has also streamlined the User Account
Control (UAC) functionality to make it less intrusive. Some security
pundits have decried this action because it actually makes Windows 7 a
little less secure. However, the other side of the coin is that users
are less likely to ignore warnings that they see occasionally, rather
than ones they see as part of nearly every action.
In fact, developers and administrators alike often see
auditing as just another step along the road toward the world of Big
Brother described in the book 1984. See http://en.wikipedia.org/wiki/Big_Brother_(Nineteen_Eighty-Four) for details. However, auditing has many practical uses:
Regulatory compliance requirements
Business compliance requirements
Application monitoring and debugging
Trojan, virus, and other forms of malware detection
Resource control
Internal threat monitoring
2. UNDERSTANDING BASIC NT SECURITY
Many developers view Windows NT security as
difficult. However, the concepts behind Windows NT security are actually
quite simple. When you leave your house, you close the door and lock
it. The lock is a kind of security that you place on your house. Only
someone with an appropriate key can access the house once you lock it
(let's assume for a moment that intruders lack tools such as pry bars).
The lock is a kind of access control, while the key is a right to access
the house. Windows NT security works precisely this way. A resource,
such as a file, has a lock on it that provides access control, while a
user has a privilege (the key) that grants permission to use the
resource in some way.
Let's take access to your house to the next level.
The front door is only one level of access. You might have locked rooms,
a safe, gun cabinet, or other elements in the house that require
additional permissions to access. The main reason for these additional
permissions is that the contents of the room or safe are especially
valuable or perhaps unsafe. You might not want your children accessing
them. To access these additional elements, you have a combination,
additional keys, or other means of access. In other words, you have
additional permissions not shared by everyone in the household. Windows
NT security works in the same way. Most resources provide multiple
levels of permissions that some users enjoy and others don't.
Access comes in two forms in Windows NT security. A
user has personal rights that are assigned directly to that user — akin
to the keys someone has on his or her key ring. In addition, a user can
belong to a group of users who all share the same rights — akin to the
key under the doormat that everyone in the house knows about and uses.
It's important to understand that the user's access is limited to the
combination of group and individual rights that the administrator
assigns.
Rights are assigned by two parties. Administrators
assign rights to users by changing the Windows configuration directly
with a Microsoft-supplied utility, such as the security editor shown in Figure 1.
Likewise, a developer can write code that sets Windows security for
particular objects, calls, and portions of an application. When the
developer couples this level of security with application settings, the
administrator can achieve better security without losing any
flexibility. In both cases, changes by the administrator or developer
affect the rights required to perform specific tasks using resources
such as a file. The right to write to a file is separate from the right
to read from the file.
User-level access depends on a Security IDentifier
(SID, usually pronounced "Sid," like the name). When the user first logs
in to the system, Windows assigns an access token to the user and
places the user's SID (stored on the domain controller or other security
database) within it. The user object carries around both the access
token and the SID for the duration of the session. An access token also
contains both a Discretionary Access Control List (DACL, pronounced "dackel") and a System Access Control List
(SACL, pronounced "sackel"). The combination of Access Control Lists
(ACLs) and SID within the access token is a key that allows the user
access to certain system resources. Because this access lasts the entire
session, the user must log out and then back in to the system whenever
the administrator makes a change to security; otherwise, the user won't
gain additional rights that the administrator provides.
A key is no good without a lock to open. The lock
placed on Windows resources is called a security descriptor. In essence,
a security descriptor tells what rights the user needs to access the
resource. If the rights within the ACLs meet or exceed the rights in the
security descriptor, then the lock opens and the resource becomes
available. Figure 10-2
shows the contents of the ACL and the security descriptor used for
token-based security. The following sections provide more details about
how token-based security actually works, using Figure 2 as the point of discussion.
2.1. Working with ACLs
There are two ways of looking at a user's rights
under Windows: individual rights and group rights. The user's SID is the
account number that Windows assigns to the user during login. The
access token that holds the SID also contains other structures that
identify the groups the user belongs to and what privileges the user
has. Each group entry also has a SID. This SID points to other
structures that describe the group's rights. To understand the user's
rights, you need to know both the user's individual rights and the
rights of the groups to which the user belongs. An administrator
normally uses the Local Users and Groups or the Active Directory Users
and Computers Microsoft Management Console (MMC) snap-in to change the
contents of this access token, as shown in Figure 3.
(To use this feature, right-click an entry, such as Guest, choose
Properties from the Context menu, and select the Member Of tab to change
the user's group affiliations.)
The privileges section of the access token shown in Figure 2
begins with a count of the number of privileges the user has — the
number of special privilege entries in the access token. This section
also contains an array of privilege entries. Each privilege entry
contains a Locally Unique IDentifier (LUID) — essentially a pointer to
the entry object — and an attribute mask. The attribute mask tells what
rights the user has to the object. Group SID entries are essentially the
same. They contain a privilege count and an array of privilege entries.
One of the things you need to know as part of working
with some kinds of objects is that object rights flow down to the
lowest possible node unless overridden by another SID. For example, if
you give the user read and write privileges to the \Temp directory on a hard drive, those rights will also apply to the \Temp\Stuff
directory unless you assigned the user specific rights to that
directory. The same holds true for containers. Assigning a user rights
to a container object like a Word document gives the user the right to
look at everything within that container, even other files in most
cases. It's important to track a user's exact rights to objects on your
server using security surveys, since you could inadvertently give the
user more rights than needed to perform a certain task.
2.2. Understanding the Security Descriptors
At this point, you have a better idea of how the
access token (the key) works. It's time to look at the security
descriptor (the lock). Figure 10-2 shows that each security descriptor contains five main sections. The following list describes each section.
Header and Flags:
The header consists of version information and a list of control flags.
The flags tell you the descriptor status. For example, the SE_DACL_PRESENT
flag indicates the presence of a DACL. If the DACL is missing, then
Windows allows everyone to use the object. The basic security
descriptors haven't changed since Windows 2000, so you can see a list of
basic security descriptors at http://technet.microsoft.com/library/cc962005.aspx. The overview at http://technet.microsoft.com/library/cc961978.aspx provides additional information about Windows security flags.
Owner SID:
Tells who owns the object. This doesn't have to be an individual user;
Windows allows use of a group SID here as well. The limiting factor is
that the group SID must appear in the token of the person changing the
entry. In other words, you can't assign ownership to a group where you
don't have membership.
Group SID:
Tells which group owns the object. This entry contains only the main
group responsible for the object and won't contain a list of all groups
with access to the object.
SACL:
Controls the Windows auditing feature. Every time a user or group
accesses an object when the auditing feature for that object is on,
Windows makes an entry in the audit log. There's more than one entry in
this section, in most cases, so Windows stores the information in an
array.
DACL:
Controls object use. Windows assigns groups and users to a specific
object. In most cases there's more than one entry in this section, so
Windows stores the information in an array. A DACL can contain a custom
value, a default value, or a null (empty) value, or it may not
appear in the security descriptor at all (this last option is rare and
dangerous). You'll normally find more objects with default values than
any other DACL type.
2.3. Understanding the ACEs
As previously mentioned, a security descriptor relies
on a SACL and a DACL to control the security of an object. Both
elements use the same basic ACL data structure, but for different
purposes. An ACL consists of two entry types. The first is a header that
lists the number of Access Control Entries (ACEs) in the ACL. Windows
uses this number to determine when it's reached the end of the ACE list.
(There isn't any end-of-structure record or other way to determine the
size of each ACE in the structure.) The second entry is an array of
ACEs.
An ACE defines the object rights for a single user or
group. Every ACE has a header that defines the type, size, and flags
for the ACE. It includes an access mask that defines rights a user or
group has to the object. Finally, there's an entry for the user or group
SID.
There are four main ACE header types (you can find the full list of ACE headers at http://msdn2.microsoft.com/library/aa374912.aspx).
Windows currently uses three out of the four main ACE header types. The
following list tells you about each of the main header types:
General Access:
This header type appears in the DACL and grants object rights to a
user. Use it to add to the rights a user already has for an object on an
instance-by-instance basis. For example, you might want to prevent the
user from changing the system time so that you can keep the machines on
the network synchronized. However, there might be one situation — such
as daylight saving time — when the user would need this right. You could
use an access-allowed ACE to allow the user to change the time in this
one instance.
Object Access:
This header type appears in the DACL and helps Windows assign specific
security to software objects and sub-objects. A developer must provide
special code to provide this access. For example, the developer could
use this type of ACE to assign security to the property of a COM object.
To use this type of ACE, the developer needs to obtain or create a
globally unique identifier (GUID) for the object in question. Once the
developer adds the required code, application settings can allow the
administrator to control access to particular application features at
run time.
System Audit:
This ACE header type works with the SACL. It defines which events to
audit for a particular user or group. There are system audit header
types for both general and object use. The .NET Framework doesn't
provide a specific auditing feature, so you can use this feature when
you want to know who's accessing a particular Website feature and when
they access it. This feature requires that the user log in to the
system. Yes, it does work with anonymous access, but all you'll see is
the anonymous user information.
System Alarm: This is the currently unused ACE type. It enables either the SACL or DACL to set an alarm when specific events happen.
