Comparing Group Policy in Windows Server 2008 to SELinux in Red Hat 

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