Glenn Brunette

I have been writing about the Immutable Service Container project for quite some time. Since this project was publicly launched earlier this year, we have produced a number of updates, several presentations and podcasts, as well as images that people could use on Amazon EC2 or with VirtualBox. All of these updates had a singular goal - to highlight what is possible when we refactor our existing strategies and processes to pre-integrate greater security capabilities by default into our operating system configurations. While our original goal was to focus on Cloud Computing and virtual machine image security, these concepts really apply more universally. Whether used in a traditional data center or the Cloud, there are significant benefits that can be realized when we begin to put all of the pieces into place. Certainly, I mean more than just patching or hardening, but looking at virtual machine security more comprehensively.

With this as a backdrop, I am very happy to announce the availability of version 1.3 of the OpenSolaris Immutable Service Container Construction Kit! Prior to this update, the Kit was able to automate the creation of a configuration that included:

• built upon the OpenSolaris 2009.06 release
• (optional) loose minimization support to help those building and sharing images
• security hardening of the operating system - based upon the OpenSolaris Security Hardening project
• non-executable stack functionality enabled (on systems supporting this functionality)
• encrypted swap enabled
• encrypted scratch space enabled - default size is 100 Mbytes (customize as needed)
• kernel-level auditing enabled - default policy audits login/logouts, administrative events, and all commands executed on the system, audit syslog plugin configured (/var/log/auditlog)
• stateful packet filtering enabled - packet filtering syslog plugin configured (/var/log/ipflog), in-bound network access denied by default (except SSH), out-bound network access permitted by default (customize as needed)
• a single non-global zone installed (although others can be installed as needed):
  • gzip compressed non-global zone root file system
  • building upon default non-global zone security capabilities
  • unique VNIC limiting visibility of unintended network traffic
  • encrypted scratch space
  • stateful packet filtering and NAT to restrict network-access
  • in-bound network access denied by default (customize for your service)
  • out-bound network access permitted by default (customize as needed)
  • DNS and auditing configurations inherited from the global zone

The v1.3 update goes beyond this foundation to incorporate new capabilities including:

• configurable virtual network architecture. Non-global zones can be installed into the same or different virtual networks. This capability is required in order to begin constructing ISC configurations that implement more advanced network compartmentalization configurations. Administrators can define to which network a non-global zone should be attached using the -N option to the iscadm.ksh tool.
• anti-spoofing protection. Each of the non-global zones are configured to leverage the MAC and IP address anti-spoofing protections enabled by Crossbow 1.3 (builds 126 and newer).
• default resource controls. Non-global zones are configured to have a maximum lightweight process resource control installed (default: 300). This setting helps to mitigate against the effects of certain denial of service attacks. The actual limit can be adjusted using the ISC_MAX_LWPS parameter.
• default file system quotas. Non-global zone root file systems are configured to have a specific ZFS quota (default: 1G) and reservation (default: 512M). Since ISC nodes (non-global zones) share a common ZFS data set, it is important to have this restriction to prevent one node from exhausting capacity being used by other nodes. The default values can be changed using the ISC_QUOTA and ISC_RESERVATION parameters.
• site variable override. A new file (isc/etc/site.conf) is used to store any variables that are specific to a site or implementation. This file is not delivered by default and therefore will not be overwritten upon update (preserving any site-specific parameters). This file is intended to be used to store local (site specific) variables such as those listed above.

In addition to these new features and capabilities, several bugs were squashed and the code was generally cleaned up to make it easier to read and extend in future updates. This update was tested using OpenSolaris 2009.06 as well as OpenSolaris 2010.03 (build 127).

It is worth noting that the OpenSolaris ISC Construction Kit uses a modular architecture. Let's say you did not want all of the functionality described above - you just want to harden an OpenSolaris global zone. Well, that can be easily done using the following steps:

$ env ISC_SVCS_DOCK="lockdown" pfexec isc/bin/iscadm.ksh -d

Similarly, if you just wanted just to try out encrypted scratch space and encrypted swap, you could use the command:

$ env ISC_SVCS_DOCK="encrypted_scratch encrypted_swap" pfexec isc/bin/iscadm.ksh -d

The goal of the Kit is to provide a fast, automated, and easy way to implement strong security protections for your systems and virtual machines, but we also recognize that requirements do differ so customization must be a core part of the software architecture.

As always, we would love to hear from you! Let's us know what works and what doesn't! What would you like to see in a future update? Is there anything that you would like to see changed? Here is your chance - speak up!

Take care!

Technorati Tag: OpenSolaris security cloudcomputing virtualization