Wednesday Nov 04, 2009
I have to say that it has been a very busy couple of weeks. That said, I am happy to say that there is a lot to show for everyone's effort however. We have been able to publish quite a lot of new and updated content, and I figured that it might be a good time to shine a spotlight on some of the more interesting items. Without further ado...
Going forward, we are going to try and bring together all of the Cloud Computing security content on our brand new Sun.COM Cloud Security home page. Be sure to check it out regularly!
More is coming, don't miss it!
Technorati Tag:
OpenSolaris
security
cloudcomputing
virtualization
Wednesday Nov 04, 2009
Today, I am very happy to announce the availability of a new Solaris 10 Security Deep Dive training. This version has been updated for Solaris 10 10/2009 (also known as Update 8). From a security perspective, there have only been a few updates since my last posted version, but it is always good to be current. Items added in this new version include: ZFS user and group quotas, ZFS pre-defined ACL sets, NTPv4, and nss_ldap shadowAccount support. In addition, there was a bit of cleanup throughout and a new example was added for Trusted Extensions.
As usual, I have made this content available in both OpenDocument Format (ODF) and PDF. If you are using Microsoft Office, you can use the Sun MS Office ODF Plugin to read the source document.
For those of you who have downloaded one of the previous versions, thank you! There have been nearly 8,000 downloads of this presentation so far! If you have not had a chance, I would encourage you to download and check out a copy today. It is really amazing how many new and updated security features and capabilities there are in Solaris 10. If you have been away from Solaris (even Solaris 10) for a while, I am sure you will be shocked with what you can do today! As always, feedback is greatly appreciated!
Take care!
Glenn
Technorati Tag:
OpenSolaris
Solaris
security
Monday Nov 02, 2009
Just in time for the OpenSolaris Developer Conference, we were able to publish new Immutable Service Containers images directly to
the Amazon Web Services Elastic Compute Cloud (EC2) environment. Previously, I talked about creating ISCs using our security enhanced OpenSolaris 2009.06 AMIs. Today, I am happy to announce that we have taken the next logical step by making available AMIs that fully incorporate the ISC changes. If you want to try out this configuration, simply provision an Immutable Service Containers AMI on EC2. We have made AMIs available in both the U.S. (ami-48c32021) and European (ami-78567d0c) regions. As always, we would love to get your feedback on these images and what you would like to see next!
Take care!
Technorati Tag:
OpenSolaris
security
cloudcomputing
virtualization
auditing
hardening
amazon
aws
ec2
Monday Nov 02, 2009
Just wanted to let everyone know of a new Immutable Service Containers technical presentation (ODF, PDF) that has been posted. This version was delivered last week in Dresden, Germany at the OpenSolaris Developer Conference. This presentation has all of the latest and greatest information particularly on the OpenSolaris ISC Construction Kit. As always, I would love to hear your comments and feedback!
Take care!
Technorati Tag:
OpenSolaris
security
cloudcomputing
virtualization
auditing
hardening
osdevcon
Friday Sep 11, 2009
Back in June, we released the very first security hardened virtual machine images for the Amazon Web Services Elastic Compute Cloud (EC2) environment. These original images were based upon the OpenSolaris 2008.11 release and were configured in accordance with the guidelines published by Sun the Center for Internet Security.
Since its initial release, we have provided an update to offer this image in the European Region. In August, we took another step forward with the release of a security-enhanced image based upon the OpenSolaris 2009.06 release. This image went beyond just the simple hardening of its predecessor to add functionality such as encrypted swap, non-executable stacks and auditing that was enabled by default. With such a strong foundation, it should have been no surprise that it was likely to be used as a foundation for layered functionality. Just this month, for example, we announced the release of an image pre-configured with Drupal (v6.10) along with Apache (v2.2), MySQL (v5.0), and PHP (v5.2).
In parallel, the Immutable Service Containers project was announced back in June. This project was focused on the creation of secure execution environments for services. One of the key deliverables from this project has been the OpenSolaris ISC Construction Kit (Preview) that transforms an OpenSolaris 2009.06 system into an ISC configuration. Interestingly, several of the functional elements used today as part of the security-enhanced AMIs actually got their start as part of the ISC Construction Kit.
This brings us to today. For the first time, we have been able to create ISCs in the Cloud on Amazon EC2! Using the OpenSolaris ISC Construction Kit and the security-enhanced OpenSolaris 2009.06 AMI, we have deployed an ISC that exposes a representative service (in this case, a web server).
HELLO WORLD!
The nice thing about this is that the installation process was essentially the same as the one we used to create our pre-configured OVF image. There were two settings that needed to be adjusted in order for the ISC Construction Kit to properly work on EC2:
export ISC_SVCS_DOCK="fs network zone encrypted_scratch"
export ISC_DOCK_NET_IF_NAME="xnf0"
These two parameters had to be set before running the iscadm.ksh command. The first parameter simply removes steps that have already been completed in the base AMI (or are not needed for EC2). The second parameter changes the network interface name from e1000g0 (default) to xnf0 which is needed on EC2. That's all there was to it!
If you are interested in ISCs and how you can use them in your environment, I would love to hear from you! Also, just in case you missed it, I had the pleasure of joining Hal Stern to discuss ISCs on a recent Innovating@Sun podcast. Check it out and send us your feedback! Thanks in advance!
Take care!
Technorati Tag:
OpenSolaris
security
cloudcomputing
auditing
hardening
Amazon
ec2
aws
Wednesday Sep 02, 2009
Over the last few months, I have had a number of postings that have talked about security enhanced virtual machine images that we have made available on Amazon Web Services. The goal behind this work was to look at how we could improve baseline security in both virtualized and Cloud Computing computing environments by pre-integrating industry accepted recommended security settings. Organizations leveraging our work would have fewer security steps to undertake as our images were configured to be compliant with the recommendations published by the Center for Internet Security as part of their Solaris Benchmark (adapted for OpenSolaris).
So with this goal in mind, we developed security-enhanced versions of the OpenSolaris 2008.11 and 2009.06 operating systems. The latter went beyond the Center for Internet Security recommendations by also adding support for encrypted swap (as well as enabling auditing and non-executable stacks by default - something that was not done for the 2008.11 version). The next logical step was to validate these images using representative applications and services to illustrate the practiality of having security capabilities pre-integrated into a golden image from which application specific versions can be created.
Building upon the lessons we have learned in the development of the security-enhanced operating system images, today, I am very happy to announce that we have taken a step forward. Using the OpenSolaris 2008.11 image as our foundation, the OpenSolaris on EC2 team with some guidance from Scott Mattoon (all around Drupal Guru!) has installed and pre-configured Drupal (v6.10) along with Apache (v2.2), MySQL (v5.0), and PHP (v5.2). You can read all of the details on the announcement.
There are two things that should be noted about this image. First, no security-relevant changes were necessary to successfully install, configure and test Drupal on this security-enhanced image. While this should likely not come as a surprise, it is an important validation that at least for some (many?) classes of applications, a security tuned golden image can be used as a foundation. This is good news for organizations who are interested in the having a common security baseline for their operating systems. The second thing to note is that MySQL was modified on this image to not listen on the network for connections. This means that the image is compliant with our original security objectives in that it is only exposing required services (e.g., Apache, SSH) and no others by default.
As with all of the others, this is a publicly available AMI (AMI ID: ami-d9ee0eb0) so give it a try and let us know how we can improve it!
Take care!
Technorati Tag:
security
auditing
hardening
cloudcomputing
OpenSolaris
Amazon
ec2
aws
drupal
Tuesday Aug 25, 2009
Things have certainly been busy around here lately! Over the last two months, we have announced the Immutable Service Container project, published an OpenSolaris-based ISC Construction Kit (Preview) and a corresponding pre-configured OVF image, shared a number of network architecture and autonomic security models leveraging the ISC concept, and even published an ISC Technical Overview presentation. Well, as it turns out, we are not done yet!
A few weeks back, I received an invitation from Marianne Salciccia to record an Innovation@Sun interview with Hal Stern (Distinguished Engineer and VP, Global Systems Engineering) where we would talk about Immutable Service Containers. I am happy to say that as of yesterday, the podcast is live!
Hal and I had a great chat where we discussed topics such as:
- micro-virtualization: how adding a thin management layer between the hypervisor and the service lends reliability to security enforcement and monitoring controls
- how "immutable" Immutable Service Containers are
- how ISCs implement defense in depth measures
- current implementations with Solaris and OpenSolaris
- what's next for ISCs, including building core concepts into projects such as OpenSolaris on EC2, OpenSolaris Just Enough OS (JeOS); potential VirtualBox implementations; and integration of autonomic security techniques
If these topics sound interesting, please give the podcast a listen and let us know what you think! Work continues on the ISC architectural strategies and implementation models, so this is a great time to share your ideas, concerns, and requirements.
Hope to hear from you soon! Take care!
Technorati Tag:
architecture
security
cloudcomputing
virtualization
Friday Aug 14, 2009
It is with great pleasure that I can announce the availability of security enhanced OpenSolaris 2009.06 on Amazon EC2! This release builds upon the work previously completed for the hardened OpenSolaris 2008.11 images as well as recent advances from the Immutable Service Container project. The end result is a OpenSolaris 2009.06 virtual machine image that is hardened, leverages a non-executable stack, encrypted swap as well as auditing enabled and pre-configured to record administrative events, logins, logouts, and all command executions. Just as with the OpenSolaris 2008.11 images, the hardening configuration of these new images complies with the recommendations published by Sun, the Center for Internet Security as well as the U.S. National Security Agency. This really cool thing is that they are all have the exact same guidance! I wonder how that happened?
Want to give it a spin? Check out the release announcement for more details. The AMI identifier is ami-e56e8f8c! Please send us your feedback!
As always, this work would not have been possible without the extensive support of the OpenSolaris on EC2 team. You are the greatest! Thank you so much for all of your help and support in making these images a reality!
Technorati Tag:
security
auditing
hardening
cloudcomputing
OpenSolaris
Amazon
ec2
aws
Thursday Jul 09, 2009
Recently, I had the pleasure of exchanging e-mail with István Soós who had contacted our OpenSolaris on EC2 team asking how he could use OpenSolaris along with Amazon's Elastic Compute Cloud (EC2) and Elastic Block Stores (EBS) to create a subversion-based source code control system. Sounds simple, right? Well, István threw us a curve ball. He wanted the revision control system to run on OpenSolaris and be stored on an encrypted, mirrored ZFS file system backed by EBS. Now, you have to admit, that is pretty cool!
This is the point in the story where István met. After going over the requirements, it appeared as though the encrypted scratch space work that had been done for the Immutable Service Container project was a near fit except that persistence was needed. So, I provided István with links to this work which of course linked to Darren's original article on ZFS encryption using LOFI. Just a day later, István replied that his environment was up and running! Talk about speed and agility in the Cloud Computing world!
I would definitely encourage you to check out all of the details on István's blog. I especially want to thank István for sharing this great article that I hope will encourage others to try new things and keep pushing the OpenSolaris envelope forward!
Take care!
Technorati Tag:
security
encryption
OpenSolaris
Cloud
Cloud Computing
zfs
Tuesday Jul 07, 2009
In my last post, I discussed the Immutable Service Container project and announced the availability of an ISC Construction Kit to automate the creation of OpenSolaris-based ISCs.
Today, I wanted to provide a few updates. Specifically, I would like to announce:
- a new Immutable Service Container presentation (ODP, PDF) that provides a technical overview of the ISC approach, design goals, and the OpenSolaris implementation available today.
- an updated Private Virtual Network architecture page highlighting additional network topologies that implement different network isolation strategies. These are a few of the models that are being considered for future ISC Construction Kit updates.
- an updated Autonomic security architecture page that provides a number of use cases showing ISCs as an essential building block for these kinds of architectures.
Additional architectural content is in development and as always I am very interested in your feedback and ideas.
Take care!
Technorati Tag:
OpenSolaris
security
cloudcomputing
Wednesday Jul 01, 2009
While the need for security and integrity is well-recognized, it is less often
well-implemented. Security assessments and industry reports regularly show
how sporadic and inconsistent security configurations become for organizations
both large and small. Published recommended security practices and settings
remain unused in many environments and existing, once secured, deployments
suffer from atrophy due to neglect.
Why is this? There is no one answer. Some organizations are simply unaware of
the security recommendations, tools, and techniques available to them. Others
lack the necessary skill and experience to implement the guidance and maintain
secured configurations. It is not uncommon for these organizations to feel
overwhelmed by the sheer number of recommendations, settings and options. Still
others may feel that security is not an issue in their environment. The list goes
on and on, yet the need for security and integrity has never been more important.
Interestingly, the evolution and convergence of technology is
cultivating new ideas and solutions to help organizations better protect their
services and data. One such idea is being demonstrated by the Immutable Service Container
(ISC) project. Immutable Service Containers are an architectural deployment pattern
used to describe a platform for highly secure service delivery. Building upon concepts
and functionality enabled by operating systems, hypervisors, virtualization, and
networking, ISCs provide a secured container into which a service or set of
services is deployed. Each ISC embodies at its core the key principles inherent
in the Sun Systemic
Security framework including: self-preservation, defense in depth, least
privilege, compartmentalization and proportionality. Further, ISC design borrows
from Cloud Computing principles such as service abstraction, micro-virtualization,
automation, and "fail in place".
By designing service delivery platforms using the Immutable Service Containers mode,
a number of significant security benefits:
- For application owners:
- ISCs help to protect applications and services from tampering
- ISCs provide a consistent set of security interfaces and resources for applications
and services to use
- For system administrators:
- ISCs isolate services from one another to avoid contamination
- ISCs separate service delivery from security enforcement/monitoring
- ISCs can be (mostly) pre-configured by security experts
- For IT managers:
- ISCs creation can be automated, pre-integrating security functionality making them
faster and easier to build and deploy
- ISCs leverage industry accepted security practices making them easier to audit and
support
It is expected that Immutable Service Containers will form the most basic
architectural building block for more complex,
highly
dynamic and autonomic
architectures. The goal of the ISC project is to more fully describe the architecture
and attributes of ISCs, their inherent benefits, their construction as well as to
document practical examples using various software applications.
While the notion of ISCs is not based upon any one product or technology, an
instantiation has been recently developed using
OpenSolaris 2009.06. This instantiation offers a pre-integrated configuration
leveraging OpenSolaris security recommended practices and settings. With ISCs,
you are not starting from a blank slate, but rather you can now build upon the
security expertise of others. Let's look at the OpenSolaris-based ISC more closely.
In an ISC configuration, the global zone is treated as a system controller and
exposed services are deployed (only) into their own non-global zones. From a
networking perspective, however, the entire environment is viewed as a single
entity (one IP address) where the global zone acts as a security monitoring and
arbitration point for all of the services running in non-global zones.
As a foundation, this highly optimized environment is pre-configured with:
Further, the default OpenSolaris ISC uses:
- Non-Global Zone. Exposed services are deployed in a non-global zone. There they can take advantage of the core security benefits enabled by OpenSolaris non-global zones such as restricted access to the kernel, memory, devices, etc. For more information on non-global zone security capabilities, see the Sun BluePrint titled "Understanding the Security Capabilities of Solaris Zones Software". Using a fresh ISC, you can simply install your service into the provided non
-global zone as you normally would.
Further in the ISC model, each non-global zone has its own encrypted scratch space (w/its own ephemeral key), its own persistent storage location, as well as a pre-configured auditing and networking configuration that matches that of the global zone. You do not need to use the
encrypted scratch space or persistent storage, but it is there if you want to take advantage of it. Obviously, additional resource controls (CPU, memory, etc.) can be added as necessary. These are not pre-configured due to the variability of service payloads.
- Solaris Auditing. A default audit policy is implemented in the global zone and all non-global zones that tracks login and logout events, administrative events as well as all commands (and command line arguments) executed on the system. The audit configuration and audit trail are kept in the global zone where they cannot be accessed by any of the non-global zones. The audit trail is also pre-configure
d to be delivered by SYSLOG (by default this information is captured in /var/log/auditlog).
- Private Virtual Network. A private virtual network is configured by default for all of the non-global zones. This network isolates each non-global zone to its own virtual NIC. By default, the global and non-global zones can freely initiate external communications, although this can be restricted if needed. A non-global zone is not permitted to accept connections, by default. Non-global zone service
s can be exposed through the global zone IP address by adjusting the IP Filter and IP NAT policies (below).
- Solaris IP NAT. Each non-global zone is pre-configured to have a private address assigned to its virtual NIC. To allow the non
-global zone to communicate with external systems and networks, an IP NAT policy is implemented. Outgoing connections are masked using the
IP address of the global zone. Incoming connections are redirected based upon the port used to communicate. Beyond simple hardening of the non-global zone (a state which can be altered from within the non-global zone itself), this mechanism ensures that the global zone can control which services are exposed by the non-global zone and on which ports.
- Solaris IP Filter. A default packet filtering policy is implemented in the global zone allowing only DHCP (for the exposed network interface) and SSH (to the global zone). Additional rules are available (but disabled) to allow access to non-global zones on an as-needed basis. Further, rules are implemented to deny external access to any non-global zone that has changed its pre-assigned (private) IP address. Packet filtering is pre-configured to log packets to SYSLOG (by default this information is captured in /var/log/ipflog).
So what does all of this really mean? Using the ISC model, you can deploy your services in a micro-virtualized environment that offers protection against kernel-based root kits (and some forms of user-land root kits), offers flexible file system immutability (based upon read-only file systems mounted into the non-global zone), can take advantage of process least privilege and resource controls, and is operated in
a hardened environment where there is a packet filtering, NAT and auditing policy that is effectively out of the reach of the deployed service. This means that should a service be compromised in a non-global zone, it will not be able to impact the integrity or validity of the auditing, packet filtering, and NAT configuration or logs. While you may not be able to stop every form of attack, having reliable audit trails can significantly help to determine the extent of the breach and facilitate recovery.
The following diagram puts all of the pieces together:
Additional private virtual networking models are also being considered. All in all, the ISC model offers a very compelling deployment model. The accessiblity and attractiveness of this model is further enhanced by the availability of an ISC construction kit that allows you to take an OpenSolaris 2009.06 system and convert it to the ISC model with a single command. Sound interesting? Give it a try, come join the project and be sure to send along your feedback
!
Technorati Tag:
OpenSolaris
security
cloudcomputing
Tuesday Jun 16, 2009
Building upon the v0.4 release of the Cloud Safety Box tool, I am happy to announce the availability of v0.3 of the Encrypted ZFS Backups to the Cloud code. This new version uses the Cloud Safety Box project to enable compression, encryption and splitting of the ZFS backups before uploading the results to the Cloud. Due to this change, this project now officially depends upon the Cloud Safety Box project. The nice thing about this change is that it helps to keep the amount of redundant code low (between the two projects) while also improving testing time.
From an end-user perspective, this change is mostly transparent. A few parameters were added or changed in the /etc/default/zfs-backup-to-s3 defaults file such as:
# ENC_PROVIDER defines the cryptographic services provider used for
# encryption operations. Value values are "solaris" and "openssl".
ENC_PROVIDER="solaris"
# MAX_FILE_SIZE specifies the maximum file size that can be sent
# to the Cloud storage provider without first splitting the file
# up into chunks (of MAX_FILE_SIZE or less). This value is specified
# in Kbytes. If this variable is 0 or not defined, then this service
# will _not_ attempt to split the file into chunks.
MAX_FILE_SIZE=40000000
# S3C_CRYPTO_CMD_NAME defines the fully qualified path to the
# s3-crypto.ksh program which is used to perform compression,
# encryption, and file splitting operations.
S3C_CRYPTO_CMD_NAME=""
# S3C_CLI_CMD_NAME defines the fully qualified path to the program
# used to perform actual upload operations to the Cloud storage
# provider. This program is called (indirectly) by the
# s3-crypto.ksh program defined by the S3C_CRYPTO_CMD_NAME variable
# above.
S3C_CLI_CMD_NAME=""
It should be noted that compression is always enabled. If this turns out to be a problem, please let me know and we can add a parameter to control the behavior. I would like to try and keep the number of knobs under control, so I figured we would go for simplicity with this release and add additional functionality as necessary.
Encryption is always always enabled. In this release you have the choice of the OpenSSL or Solaris cryptographic providers. Note that just as with the Cloud Safety Box project, key labels are only supported for the Solaris cryptographic provider. The name of the algorithm to be used must match the algorithm name supported by whichever provider you have selected.
File splitting is enabled by default. This behavior can be changed by setting the MAX_FILE_SIZE parameter to 0 (off) or any positive integer value (representing a size in Kbytes).
All of the other changes are basic implementation details and should not impact the installation, configuration or use of the tool. If you have not had a chance, I would encourage you to check out the
ZFS Automatic Snapshot as well as the latest version of this project so that you can begin storing compressed, encrypted ZFS backups into Amazon's Simple Storage Service (S3) or Sun's SunCloud Storage Service (when available).
As always, feedback and ideas are greatly appreciated! Come join the discussion at Project Kenai!
Take care!
Technorati Tag:
OpenSolaris
security
zfs
encryption
cloudcomputing
Monday Jun 15, 2009
It has sure been a busy month and really it has just begun. Today, I am happy to announce the availability of my Solaris 10 Security Deep Dive presentation, updated for the just released Solaris 10 05/2009 (Update 7). From a security perspective, there have only been a few updates since my last posted version, for Solaris 10 10/2008 (Update 6), but it is always good to be current. Of particular interest is a new slide focused on IPsec and IKE. As usual, I have made this content available in both OpenDocument Format (ODF) and PDF. If you are using Microsoft Office, you can use the Sun MS Office ODF Plugin to read the source document.
For those of you who have downloaded one of the previous versions, thank you! There have been nearly 5,000 downloads of this presentation so far! If you have not had a chance, I would encourage you to download and check out a copy today. It is really amazing how many new and updated security features and capabilities there are in Solaris 10. If you have been away from Solaris (even Solaris 10) for a while, I am sure you will be shocked with what you can do today! As always, feedback is greatly appreciated!
Take care!
Glenn
Technorati Tag:
OpenSolaris
Solaris
security
hardening
Friday Jun 12, 2009
Last week, I announced the availability of a set of scripts that could be used to enable encrypted swap in OpenSolaris 2009.06. Building upon this concept, today, I am happy to announce a new set of scripts that enables the creation of an encrypted file system (intended to be used as scratch space).
The method for creating these encrypted file systems is similar to the approach discussed by Darren in his posting on the topic of Encrypting ZFS Pools using LOFI. I had been working on a similar model for the Immutable Service Container project where I had wanted to be able to give each OpenSolaris zone that was created its own place to store sensitive information (such as key material) that would be effectively lost when the system was rebooted (without requiring a time-consuming disk scrubbing process).
The way these scripts work is quite simple. There is an SMF service, called isc-encrypted-scratch, that (if enabled) will automatically create encrypted scratch space for the global zone as well as any non-global zones on the system (by default). The creation of encrypted scratch space is configurable allowing you to specify which zones (including the global zone) can have one. You can specify which ZFS file system can be used as the home directory for the scratch space hierarchy. Using SMF properties and standard SMF service configuration methods, you can also specify the size of the encrypted scratch space.
Once created, you will have access to a ZFS file system (based upon a ZFS pool which itself is based upon an encrypted LOFI which itself is based upon a ZFS zvol - crazy eh?) The file systems created for the encrypted scratch space are destroyed and re-created upon boot (or service restart). Just as with the encrypted swap scripts, the encrypted LOFIs use ephemeral keys in conjunction with the AES-256-CBC cipher.
So, without further ado, let's get to the particulars. To enable encrypted scratch in OpenSolaris 2009.06, you need only follow the following steps.
Note that the following instructions assume that privileged operations will be executed by someone with administrative access (directly or via Solaris role-based access control). For the examples below, no changes were made to the default RBAC configuration. The commands as written were executed as the user created during the installation process.
- Add the Encrypted Scratch Space SMF service. First, you will need to download the archive containing the encrypted scratch space SMF service manifest and method files. Note that these files are user contributed and as such are not officially a part of the OpenSolaris release nor are they officially supported by Sun. If you are ok with these terms, you should now download the archive and install the files using the following commands:
$ wget -qnd http://mediacast.sun.com/users/gbrunette/media/smf-encrypted-scratch-v0.1.tar.bz2
$ bzip2 -d -c ./smf-encrypted-scratch-v0.1.tar.bz2 | tar xf -
$ cd ./smf-encrypted-scratch
$ pfexec ./install.sh
$ svccfg import /var/svc/manifest/site/isc-enc-scratch.xml
- Configure the Encrypted Scratch Space Service. Unlike the Encrypted Swap SMF Service, this service is not enabled automatically. This is to allow you the opportunity to adjust its configuration should you want to change any of the following properties:
- config/scratch_root. This property defines the root ZFS file system to be used for the scratch space hierarchy. By default, it is set to rpool/export. Based upon this value, a collection of scratch files will be created under this location (each in its own directory tied to the name of the zone).
- config/scratch_size. This property defines the size of the scratch space. This value is used during the initial creation of a ZFS volume (zvol) and accepts the same values as would be accepted by the zfs create -V command. The default size is 100 Mbytes. Note that today, each individual encrypted scratch space on a single system must be the same size.
- config/zone_list. This property defines the zones for which encrypted scratch space will be created. By default, this is all zones including the global zone. Setting this value to a zone or list of zones will cause encrypted scratch spaces to be only created for those specified.
For example, to configure this service to create 1Gbyte encrypted scratch spaces, use the command:
$ svccfg -s isc-encrypted-scratch setprop config/scratch_size = 1g
$ svcadm refresh isc-encrypted-scratch
- Enable the Encrypted Scratch Space Service. Once you have finished configuring the service, you can enable it using the standard SMF method:
$ svcadm enable isc-encrypted-scratch
- Verify the Encrypted Scratch Space Service. To verify that the service is operating correctly, you can use the following commands to verify that everything has been properly created. First, let's make sure the service is running:
$ svcs isc-encrypted-scratch
STATE STIME FMRI
online 12:40:02 svc:/system/isc-encrypted-scratch:default
Next, let's verify that all of the proper ZFS mount points and files have been created. Note that the scratch root in this case is the default (rpool/export) and under this location a new scratch file system has been created under which there is a file system for each zone on the system (global and test). For each zone, a 1 Gbyte scratch file has been created.
$ zfs list -r rpool/export/scratch
NAME USED AVAIL REFER MOUNTPOINT
rpool/export/scratch 2.00G 5.21G 19K /export/scratch
rpool/export/scratch/global 1.00G 5.21G 19K /export/scratch/global
rpool/export/scratch/global/scratch_file 1G 6.21G 1.15M -
rpool/export/scratch/test 1.00G 5.21G 19K /export/scratch/test
rpool/export/scratch/test/scratch_file 1G 6.21G 1.15M -
Next, let's verify that the encrypted LOFIs have been created. The mapping of the device files back to the actual scratch file zvols is left as an exercise for the reader.
$ lofiadm
Block Device File Options
/dev/lofi/1 /devices/pseudo/zfs@0:1c,raw Encrypted
/dev/lofi/2 /devices/pseudo/zfs@0:2c,raw Encrypted
Next, let's verify that new zpools and ZFS file systems have been created from the encrypted LOFIs:
$ zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 11.9G 4.06G 7.88G 34% ONLINE -
scratch-global 1016M 82K 1016M 0% ONLINE -
scratch-test 1016M 82K 1016M 0% ONLINE -
$ zpool status scratch-global scratch-test
pool: scratch-global
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
scratch-global ONLINE 0 0 0
/dev/lofi/1 ONLINE 0 0 0
errors: No known data errors
pool: scratch-test
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
scratch-test ONLINE 0 0 0
/dev/lofi/2 ONLINE 0 0 0
errors: No known data errors
$ zfs list /scratch-*
NAME USED AVAIL REFER MOUNTPOINT
scratch-global 70K 984M 19K /scratch-global
scratch-test 70K 984M 19K /scratch-test
- (Optional) Add Encrypted Scratch Space to a Non-Global Zone. At this point, you have everything that you need to get started. In fact, for the global zone, there are no further steps, but you can now assign the scratch space to a non-global zone (if desired) using the standard zonecfg mechanisms. For example, you could do the following:
$ pfexec zonecfg -z test
zonecfg:test> add dataset
zonecfg:test:dataset> set name=scratch-test
zonecfg:test:dataset> end
zonecfg:test> verify
zonecfg:test>
- (Optional) Verify Encrypted Scratch Space in a Non-Global Zone. Once booted, the new encrypted scratch space data set will be made available to the non-global zone:
$ pfexec zlogin test
[Connected to zone 'test' pts/2]
Last login: Fri Jun 12 09:57:43 on pts/2
root@test:~# zpool list scratch-test
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
scratch-test 1016M 74.5K 1016M 0% ONLINE -
root@test:~# df -k /scratch-test
Filesystem kbytes used avail capacity Mounted on
scratch-test 1007616 19 1007546 1% /scratch-test
root@test:~#
Upon reboot, each of the zones will be shut down before the encrypted scratch space is destroyed. Note that upon global zone or service restart, the encrypted scratch space will be re-created and therefore will not persist across global zone reboots. The encrypted scratch space will persist across non-global zone reboots.
There you have it! Enabling encrypted scratch in OpenSolaris 2009.06 (for the global and non-global zones) is as easy as following these few simple steps. It is worth stating that this solution is just a temporary workaround. Once ZFS encryption is available, it should be used instead of this approach. In the meantime, however, if you are interested in enabling encrypted scratch on your OpenSolaris 2009.06 systems, give this model at try and please be sure to send along your feedback!
Take care!
P.S. Some of you may be wondering why the SMF service and associated files are labeled with an ISC prefix? The answer is simple. They were developed and are being used as part of the Immutable Service Container project! Look for more information and materials from this project in the near future!
Technorati Tag:
security
encryption
OpenSolaris
zfs
Thursday Jun 11, 2009
Just a few days ago, I announced the availability of a security hardened OpenSolaris AMI for Amazon EC2. Well, the
OpenSolaris on EC2 team has taken the next step by making this image available to our colleagues using the EC2 European Region! This publicly available AMI (AMI ID: ami-d7a189a3) is available today, and just as with the U.S. version, it does not require registration. There is nothing to get in the way of your using them today! Go give it a spin and let us know what you think! Check out the announcement for all of the details.
Technorati Tag:
security
hardening
cloudcomputing
OpenSolaris
Amazon
ec2
aws
