System News
Protecting the Enterprise from Attacks
Mandatory Access Control and the Solaris OS
December 29, 2009,
Volume 142, Issue 5

Mandatory Access Control and Solaris OS offer tighter security
 

President and COO of Sun Microsystems Federal Bill Vass writes about developments at Sun in the area of enforcing Mandatory Access Control (MAC) with virtualization to confine Internet services with simple security configurations using the Solaris OS. Featured in the blog are the remarks of senior Sun researchers John Weeks and John Totah that explain how, in addition to enforcing MAC provisions, they also layered the MAC protection with what users ordinarily expect from employing all of the other Solaris security features combined with virtualization, eg. zones, and Internet community sponsored configuration guidelines such as the Center for Internet Security (CIS) benchmarks.

Weeks and Totah remark on the frequently overlooked capabilities that MAC can bring to a virtualized environment. In addition to filesystem MAC security, Solaris provides trusted networking to enforce MAC policy for labeled network communications, they point out. Trusted networking can be used to restrict network connections to one-way inbound connections and also to isolate administrative network access to manage the Internet services such as configuring an application server, they point out.

The use of MAC for labeled network restrictions is slightly different than only using host-based firewalls, due to the simple association of a label to communication endpoints that are compared for equality by the kernel and only if the label comparison is successful then the firewall rules are applied, Totah and Weeks explain.

The researchers continue with comments on how they have been using MAC enforcement with Solaris, based on the configuration of an address for a NIC that uses a different label from the application process that starts in a labeled zone by listening for connections using a construct called a Multi-Level Port (MLP).

They present two examples, one involving a GlassFish security container using two labeled zones which must be defined with different labels for Solaris to start. The first labeled zone is where we are running a reverse proxy server to control incoming connections destined for the second labeled zone where we have the GlassFish instance running. We restrict remote administration from another network that is specifically designated for out-of-band management. In each of the zones, we use MAC to enforce incoming connections only and we therefore have robust control over the processes that execute in the confined labeled zones.

A second example replaces the Sun GlassFish security container with a Microsoft Internet Information Services (IIS) security container using Sun VirtualBox that is running Windows Server 2008 using the "Core" installation option. The notable differences between the two examples, Totah and Weeks explain, are that GlassFish security container is using a Java Virtual Machine (VM) to execute in the restricted labeled zone and the Microsoft IIS security container is using Sun VirtualBox to execute in a restricted labeled zone.

Weeks and Totah explain how they tested the use of MAC to restrict connection initiation from Internet hosted services to an enterprise network computing environment by building an example configuration in the lab to demonstrate what could be accomplished using off-the-web components without modification to their source code.

This approach involved using a simple configuration that would easily show the basic concepts described above, which the pair found easy to use in constructing a prototype that demonstrates some of the unique value of MAC to benefit customers that are outside typical U.S. Federal Government deployments. The researchers started with a simplified system configuration with one NIC connected to the Internet, and another NIC for remote administration allowing connections from an out-of-band management network. Illustrations within the blog make the configurations clear.

The first test example uses the MAC capabilities of Solaris, the Sun GlassFish Application Server, and the Sun Java System Web Proxy Server running on an Ultra 27 Workstation. Weeks and Totah configured a virtual DMZ security container in a dedicated labeled zone where the Sun Server Java Proxy instance is running to control incoming connections destined for web services in other zones. What's unique about the MAC configuration of the virtual DMZ zone, they remark, is that the label of the Internet NIC is different from the label of the virtual DMZ labeled zone itself. This means that the MAC policy will also allow the Proxy to accept incoming connections, but will not allow the Proxy, or any other process that may run in the virtual DMZ labeled zone, to initiate any outbound connections to applications with listeners using the NIC IP address or through the NIC to any network endpoints. In addition, the pair used Solaris IP Filter with traditional host-based firewall rules for the physical NICs as a typical defense-in-depth measure.

The results revealed these virtual DMZ/Proxy security benefits:

  • Contained within a labeled zone
  • Configuration prevents any outbound Internet connections
  • Remote administration is isolated to strictly allow incoming connections from the out-of-band management network

Weeks and Totah next configured a virtual WEBAPP security container in the second labeled zone where the GlassFish instance is running and accepting connections from the reverse proxy server running in the virtual DMZ security container. The next step was to configure a dedicated NIC for the WEBAPP zone that allows access to the GlassFish Application Server Administrative port 4848 from the out-of-band management network.

The resulting configuration allows Internet web browser access through the virtual DMZ labeled zone to the WEBAPP labeled zone, and GlassFish Administrative access from the out-of-band management network, the researchers continue. Readers will notice that the administration of the GlassFish running instance is not accessible from the same network that GlassFish is listening on for the application service, nor is the GlassFish administration accessible from within the WEBAPP labeled zone where GlassFish is running. After having success with the DMZ and WEBAPP configuration, Weeks and Totah decided to apply the same concepts and methods to Microsoft IIS, where they created a new IIS labeled zone and used VirtualBox to run a Windows image as a guest operating system. The configuration was as follows:

  • Used VBox NAT to redirect listener ports (8090 8091)
  • Prevented Windows/IIS from initiating any connections to network endpoints outside of the WEBAPP labeled zone
  • Remotely administer Windows via VRDP port
  • Remotely administer IIS using IIS Manager via 8172 from the admin network

In this case, the researchers report, they utilize MAC network isolation within the system, but all external network interfaces are configured as single-level. This means that you could drop such a configuration into an existing enterprise without the need to support labeled networking using Commercial Internet Protocol Security Option (CIPSO) anywhere in an enterprise.

In a concluding section, Weeks and Totah list several other common methods to secure the system.

More Information

OpenSolaris.org Flexible Mandatory Access Control (FMAC)

Top 10 Web Application Security Vulnerabilities [...read more...]

Keywords:

fullsource
 

Other articles in the Security section of Volume 142, Issue 5:
  • Protecting the Enterprise from Attacks (this article)

See all archived articles in the Security section.



News and Solutions for Users of Solaris, Java and Oracle's Sun hardware products
Just the news you need, none of what you don't – 42,000+ Members – 24,000+ Articles Published since 1998