Beruflich Dokumente
Kultur Dokumente
Enterprise Linux 5
When choosing a server product for an IT environment, comparison shopping quickly reveals that two or
more products might seem to have similar functionality, but each has unique features that can
ultimately dictate which product is the best fit. This paper evaluates similarities and differences between
features and functions of Windows Server 2008 Group Policy and SELinux in Red Hat Enterprise Linux 5
(RHEL5).
In terms of centralized policy management, it appears that both the Microsoft’s Windows Server 2008
and RHEL5 SELinux architectures provide security polices at the individual computer and user levels. The
capability within both platforms for this type of granular control serves to reduce the burden for
Windows Server 2008 and RHEL5 IT professionals of enforcing security policies. However, the similarities
between the two platforms end here, with each taking quite different approaches to policy scope,
functionality, and management. Windows Group Policy aims to specify what functions users can
perform, while SELinux focuses on controlling what programs and data users can access. The difference
in mission is borne out of differing original objectives.
The objective of Windows Group Policy is to delegate functions to users to further enterprise operational
standards and security stance.
In Windows Server 2008, Group Policy is set at several different levels, ranging from the Active Directory
(AD) domain down to the local machine, with each policy applying to a specific user or group of users.
Windows Server 2008 enumerates specific tasks that can be secured and centrally managed: the tasks
can be enabled, disabled, or set to one of various control states.
In contrast, the objective of SELinux is to control the flow of information and limit the privilege of
programs to the least extent necessary to perform their function.
SELinux defines permission relationships between users and objects, wherein an object can be a
program or data file. Defining what functions a particular user‐run program performs falls outside the
scope of SELinux policies.
Despite these different objectives, comparing the two security models is useful and valid because each
represents the most comprehensive security framework for its respective system. Group Policy is the
most powerful security mechanism in Windows 2008 Server, and SELinux is the most powerful in RHEL5.
Let’s review exactly what policy management means for each platform. We will consider the difference
in policy concepts between the platforms; how policies are set, first in RHEL5 SELinux, and then in
Windows 2008 Server Group Policy; and what the respective settings mean for end users.
Microsoft Corp. March 2008 1
Policy Concepts in SELinux and Windows 2008
Some SELinux terms and Windows 2008 Group Policy terms are similar, but they have different
meanings within each system; understanding these differences is crucial to understanding SELinux
behavior. In SELinux, a policy is the entire set of SELinux rules for a system; under Windows Group
Policy, a policy is a single rule. An SELinux domain is the subset of rules that apply to an executable
program, whereas a Windows Domain represents a group of users and systems that share a set of
policies. Permissions under SELinux are the actions permitted by a program or user on an object, such as
read or write; Windows Group Policy permissions are the delegation of the capability to create and
modify policies for a subset of users and systems.
Policy Management via SELinux in RHEL5
The U.S. National Security Agency originally developed SELinux as a Linux security feature to help
control the flow of information within government computer systems. In particular, SELinux aims to limit
the privileges of programs and users based on their security classification, and to prevent the flow of
sensitive information out of the system. In general, SELinux prohibits any interaction not specifically
permitted by a rule in the system policy.
SELinux uses a methodology called Mandatory Access Control (MAC), by which access to services and
objects is based on system‐wide policies, called targeted policies, rather than on individual user
permissions. Targeted policies are separated into two groups: 1) the untargeted_t domain or type (these
terms are used interchangeably in SELinux), which is where most object and processes run; and 2) the
more than 200 restricted policies that are defined in RHEL5, which run in their own confined domain
space. For example, if an outside user were to breach security and gain access to squid (the Internet
proxy server), that user would not have complete control over the system because squid runs in the
domain of squid_t, which limits squid to the least privilege it needs to do its job. SELinux treats all users
and objects generically, without considering the functions a user‐run program performs. Functional
control is outside the scope of SELinux. Whether a user is an administrator or the new office temp does
not matter; neither does whether the user invokes function X or Y of a particular program. In either
case, user access is limited to the scope of the program’s authority when the user is running that
program.
Figure 1 is an example using SELinux that shows the permissions for users on the network.
Microsoft Corp. March 2008 2
Figure 1. SELinux Permissions for Network Users
SELinux policy management can be complex, and the plain‐text storage of rules makes rule analysis and
review challenging. In particular, SELinux has no direct rule‐management user interface, so rule syntax
isn’t enforced until the system processes the rules. SELinux includes a tool called SETroubleShoot as an
aide for diagnosing rule problems and conflicts.
As noted, SELinux does not perform functional control; RHEL5 has no mechanism for delegating specific
functions to users — by definition, all users can perform all functions a given program is capable of
performing. Consequently, polices change infrequently, such as when a new program is installed on the
system.
Group Policy in Windows Server 2008
Microsoft has used Group Policy in Windows since the introduction of Windows NT to reduce the
administrative burden of securing and maintaining systems, and particularly for delegating capabilities
to user desktop control. For example, an enterprise might want to enforce a specific idle timeout delay
for all users, or it might delegate that choice to users via a policy. In general, Group Policy permits
anything not specifically restricted. Previous versions of Windows left responsibility for user desktop
settings exclusively up to the Administrator. From a user‐management perspective, this approach
translated to many, often‐complex policy settings to ensure that all users were getting what they
needed without jeopardizing network integrity.
The newest incarnation of Group Policy has opened the way for more finely grained policies, while at
the same time giving users more control over the desktop “look and feel.” Group Policy in Windows
Server 2008 is divided into policies and preferences. As in the past, policies are enforced according to
hierarchy and permissions. The Group Policy Program Manager sets policies, and users cannot change
the defined settings. The Administrator sets preferences; however, these preferences are not
Microsoft Corp. March 2008 3
necessarily enforced. As their name implies, preferences are the preferred settings for users, and users
can make changes to preferences via their desktops.
Another advantage of Windows Server 2008 Group Policy is the new format and functionality of
Administrative templates, which let you extend control of your environment into additional areas of
manageability. With Administrative templates, a Group Policy Program Manager can capture collections
of polices for redistribution or offline editing.
Let’s look at some of the things Administrators and Group Policy Program Managers can set as policy
and preference using the Group Policy Management Console (GPMC). We first look at Group Policy
preferences, the newest feature of GPMC. We see how simple it is to bring up the Power Options
properties (Figure 2), and then which of those preferences we can set using the Group Policy
Management Editor (Figure 3).
Figure 2. Windows Server 2008 Power Options
Microsoft Corp. March 2008 4
Figure 3. Setting Power Options for User Groups
Microsoft Corp. March 2008 5
Next, let’s look at how we can redirect users’ Documents folders to a network share. Figure 4 shows
how easy it is to set up a share location by group for the Documents folder.
Figure 4. Group Policy Document Sharing
Conclusion
In the final analysis, the platform you choose comes down to how much control you really want to have
over your user settings, and how easy is it to implement and maintain that control. SELinux in RHEL5
offers the security of encapsulated objects that run in their own “space” to prevent compromise to the
network. This approach is effective but doesn’t permit control at the functional level. Windows Server
2008’s finely grained approach to Group Policy provides administrators with the capability to address
the security and configurability of both servers and end‐user machines.
Microsoft Corp. March 2008 6