By gbrunett on Nov 30, 2009
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.
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!