 Print-friendly Version
Practical Security Using Solaris Containers in the Solaris 10 OS -- Part IGlenn Brunette, September 2005 In the first article of this two-part series, I would like to highlight the Solaris 10 security model using containers and zones, combined with tools and technologies that are available by default in the Solaris 10 OS. I hope to show how these can provide customers with an enhanced ability to detect and contain security breaches, limit privilege escalation, and minimize installation of root kits, Trojan horses, and other malware. In this way, we can demonstrate how the use of containers, and more specifically zones, can be leveraged as part of a greater defense and in-depth security strategy. Since a great deal of material is already available on containers and zones, I will not discuss any of the basics. I would like to specifically focus on security using a Solaris Containers model, and show how zones can be leveraged to improve the security of deployed systems and services. If you would like more information on zones in general, see the BigAdmin Zones page for starters. You should also check out the BigAdmin feature article on containers and zones in the Solaris 10 OS, Spotlight on Solaris Zones Feature. The first thing that you will realize is that zones are configured to run with reduced privileges by default. In fact, today the Solaris 10 OS offers no way to alter this default. The privileges that are not available to be used within a zone are: cpc_cpu, dtrace_kernel, dtrace_proc, dtrace_user, net_rawaccess, proc_clock_hires, proc_lock_memory, proc_priocntl, proc_zone, sys_config, sys_devices, sys_ipc_config, sys_linkdir, sys_net_config, sys_res_config, sys_suser_compat, sys_time
For a description of each of these privileges, see Why is this?
Let's take an example. Let's assume that you are running some kind of exploitable service that an attacker uses to gain shell access to the system as a privileged user. For our example, let's even assume that the attacker has obtained Once attackers gain access to the system, the first thing that they would typically want to do is hide the fact that the system or service was breached. By leveraging Solaris auditing (also known as the Basic Security Module or BSM) and configuring it to run from the global zone, you are in a position to monitor and record this breach in a way that (1) attackers do not know that their actions are being monitored and (2) attackers cannot see or change the audit system, its configuration, or its logs. This is a significant improvement over using the global zone for service deployment where an attacker who has root or equivalent privilege would be able to view and even modify the audit records on the system. In addition to auditing, if extended process accounting has been configured and enabled from the global zone, then the accounting data can still be archived for the local zone even if the attacker turns off process accounting within the zone (which in fact only turns off the zone's own accounting stream).
To further hide their presence, attackers may also try to install a kernel root kit. This type of attack would be thwarted by the zones security model because local zones are not permitted to load or unload kernel modules (since local zones lack the
Attackers may also attempt to protect their level of access so that they can come back at a later time even if the vulnerability they used initially had been patched. Often this is done through the installation of root kits and Trojan horses. If the system has been configured in a sparse root configuration (which is the default), the attackers are significantly limited as to what they can install or replace since the Since attackers cannot install, modify, or remove files under these directory trees, they may look to see what they can modify. Attackers will only be able to access those file systems and devices that have been specifically assigned to the zone (regardless of what other file systems and devices are available to other zones, including the global zone). If any of the file systems are mounted read-only, then the same condition applies as noted above.
Some file systems, such as / ( Since the root file system is writable, the attacker could install a new run-control script or a service using Service Management Facility (SMF), modify service configuration files, or even add a user or change a password. All of these changes to the system can be monitored and detected, however, through the use of Solaris auditing as well as the Solaris 10 Basic Auditing and Reporting Tool (BART). BART is a file system integrity tool that can be run from the global zone. Just as with Solaris auditing, attackers would not know that they were being monitored or that their changes to the system had been detected. In fact, the zones security model combined with Solaris 10 capabilities like Solaris auditing and BART do not leave attackers with very much room to conceal the fact that they are on the system. Similarly, resource management controls can also be applied to help prevent individual zones from consuming resources required by other zones or the global zone on the system. This can help mitigate certain types of denial of service attacks. Of course, the success of this model is dependent on customers deploying services in local zones that can leverage the strength of these capabilities and tools. Resources
About the AuthorGlenn Brunette, a Sun Distinguished Engineer, is Director of the Client Solutions Security Program Office and CSO Chief Security Architect at Sun Microsystems, Inc. He writes extensively on a variety of security topics affecting Sun's customers. Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. |
 |
 | |