Tuesday Jun 16, 2009

NEW: Encrypted ZFS Backups to the Cloud v0.3

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:

Monday Jun 15, 2009

NEW: Solaris 10 Security Deep Dive Presentation

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:

Friday Jun 12, 2009

Encrypted Scratch Space in OpenSolaris 2009.06

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:

Thursday Jun 11, 2009

UPDATE: Free Security Hardened Virtual Machine Image

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:

Impacting Solaris 10 Security Guidance

It is that time again! Work is kicking up over at the Center for Internet Security to update the Solaris 10 security benchmark. As I have previously covered, Sun has been working hand-in-hand with the Center for Internet Security for more than six years to develop best-in-class security hardening guidance for the Solaris operating system.

In recent years, the NSA and DISA have jumped in contributing their time and expertise towards the development of a unified set of Solaris security hardening guidance and best practices. Now is the time for the next step. Over the last several months, these groups have been working to comb through and integrate the recommendations found in the DISA UNIX STIG (Security Technical Implementation Guide) and associated checklist as it relates to Solaris. With this work now complete, an effort has been launched to develop a new draft CIS Solaris 10 Benchmark with these additions.

In addition to this effort, a secondary effort will soon be undertaken to update the Solaris 10 Benchmark for the latest release of the Solaris 10 05/2009 (Update 7). Currently, the Solaris 10 Benchmark supports Solaris 10 11/08 (Update 4). There are not that many things added to Solaris 10 since Solaris 10 11/08 that impact the hardening guide, but there are some items that will impact the Solaris Security Appendix that was published with the last version of the Benchmark.

The reason for my post today, however, is to say that the time is right if you are interested in Solaris, security, and want to get involved! We are always looking for people with a passion to help develop and improve the recommendations and settings in the Solaris 10 Benchmark. Want to learn more? Contact CIS!

P.S. Just in case you missed it - Sun and CIS also announced the availability of a security hardened virtual machine image based upon OpenSolaris for Amazon's EC2 (SunCloud will also be supported). Give it a try!

Take care!

Technorati Tag:

Wednesday Jun 10, 2009

NEW: Cloud Safety Box v0.4

Today, I am happy to announce the v0.4 release of the Cloud Safety Box project. About a month ago, I announced the initial public release and since that time it was even highlighted and demonstrated at Sun's CommunityOne event! Not too bad for a new project!

The new version released today was a substantial redesign in order to improve the overall design and efficiency of the tools while at the same time adding a few key features. The biggest visible changes include support for compression, splitting up of large files into small chunks, and also support for Solaris key labels. Let's dive into each of these briefly:

  • Compression. Compression is enabled automatically for the Cloud Safety Box (csb) tool and it is configurable when using the s3-crypto.ksh utility. When compression is enabled, the input stream or file is compressed first (before encryption and splitting). By default, compression is formed using the bzip2 utility (with the command-line option -9. To enable compression with the s3-crypto.ksh utility, use the -C option as in the following example:
    $ s3-crypto.ksh -C -m put -b mybucket -l myfile -r myfile
    

    Of course, compression can be used along with encryption and file splitting. Decompression is handled on get operations and is the last step to be performed (after file re-assembly and decryption). Just as with compression, the bzip2 utility is used (with the command-line options -d -c. To enable decompression with the s3-crypto.ksh utility, use the -C option as in the following example:

    $ s3-crypto.ksh -C -m get -b mybucket -l myfile -r myfile
    

    The actual compression and decompression methods can be changed using the S3C_COMPRESS_CMD and S3C_DECOMPRESS_CMD environment variables respectively as in the following example:

    $ env S3C_COMPRESS_CMD="gzip -9" S3C_DECOMPRESS_CMD="gzip -d -c" \\
       s3-crypto.ksh -C -m put -b mybucket -l myfile -r myfile
    

  • Splitting. It is well known that there are file size limits associated with Cloud Storage services. There are times, however, when you may have files that you would like to store that exceed those limits. This is where splitting comes into the picture. Splitting will take an input file and based upon a size threshold, divide it up into a number of files. Splitting is done by default with the csb tool and can be optionally enabled in the s3-crypto.ksh tool. Splitting is accomplished using the GNU split(1) program and is enabled using the -S option. The maximum file size limit is, by default, set at 4 GB, but it can be adjusted using the -L command-line option (specified in Kbytes). Splitting at 2 GB is enabled in the following example:
    $ s3-crypto.ksh -S -L 2000000 -m put -b mybucket -l myfile -r myfile
    

    When splitting is enabled and triggered (when a file's size exceeds the limit), the files stored in the Cloud Storage service use the name as specified by the remote_file (-r) argument. In the above example, the split files will all begin with the name myfile. Each will have a suffix of a ~ followed by an identification string. For example, files stored in the Cloud may look like:

    myfile~aaaaa
    myfile~aaaab
    myfile~aaaac
    myfile~aaaad
    

    The csb and s3-crypto.ksh tools will use this naming convention to automatically reassemble files for get operations. Just as with splitting, reassembly is automatically performed for the csb tool and is enabled in the s3-crypto.ksh tool using the command-line option -S. When specifying a file that has been split, you do not need to include the suffix. The tools will discover that the file has been split and automatically reassemble it. Here is an example for reassembly:

    $ s3-crypto.ksh -S -m get -b mybucket -l myfile -r myfile
    

    The only downsides to splitting are the time it takes to split the files and the additional space that is needed to accommodate both the original file as well as the files created during the splitting process. This is unavoidable however as complete files must be available locally before they can be uploaded to the Cloud Storage provider.

  • Key Labels. The last "big" feature added in this new version is support for symmetric keys stored in PKCS#11 tokens (when the Solaris cryptographic provider is used). By default, the Solaris cryptographic provider is not selected (for reasons of portability), but it can easily be enabled in the s3-crypto.ksh tool using the -p solaris command line option. This setting will cause enable the use of the Solaris encrypt(1) and decrypt commands in place of their OpenSSL counterparts. Using the Solaris cryptographic provider allows you to take advantage of the Solaris Key Management Framework. Today, only the Sun Software PKCS#11 softtoken is supported, but I expect to remove this restriction in a future release.

    Using the pktool(1) command, you can create a key with a specific key label:

    $ pktool genkey keystore=pkcs11 label=my-new-key keytype=aes keylen=256
    Enter PIN for Sun Software PKCS#11 softtoken 
    Enter PIN for Sun Software PKCS#11 softtoken
    Enter PIN for Sun Software : 
    

    The creation of this new key (with label my-new-key) can be verified:

    $ pktool list objtype=key
    Enter PIN for Sun Software PKCS#11 softtoken  Enter PIN for Sun Software P: 
    Found 1 symmetric keys.
    Key #1 - AES:  my-new-key (256 bits)
    

    This key can be used with the s3-crypto.ksh tool when the Solaris cryptographic provider is selected and the key label is provided using the -K command-line option as in the following example:

    $ s3-crypto.ksh -c -p solaris -m put -b mybucket -K my-new-key -l myfile -r myfile
    Enter PIN for Sun Software PKCS#11 softtoken  : 
    

    The same approach is used to decrypt files when a get operation is specified.

As always, I am always looking for feedback! Let me know if these tools are helpful and how they can be improved! You can find out more information on this project at its home page at Project Kenai.

Take care!

Technorati Tag:

Monday Jun 08, 2009

Encrypted Swap in OpenSolaris 2009.06

Back in December 2008, LOFI encryption support was added to Solaris Nevada (build 105). With the release of OpenSolaris 2009.06, this functionality is now available as part of a released product. What does this have to do with encrypted swap you may ask? To get your answer, you need only review the lofi(7d) crypto support architectural review case (PSARC/2007/001). Toward the bottom is a section titled "Encrypted Swap". This information gives us everything that we need to enable encrypted swap on OpenSolaris -- almost.

The problem is that the encrypted swap portion of this ARC case was never completed as it is expected that the ZFS encryption project will provide this functionality when it integrates. Unfortunately, ZFS encryption is not here today, so until it is - we can enable a workaround using LOFI encryption. There are some "issues" to consider when using LOFI encryption that Darren Moffat covers well in his post on this subject.

So, without further ado, let's get to the particulars. To enable encrypted swap 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.
  • Prevent the system from automatically adding swap devices or files. This is actually a little trickier than it sounds since the /sbin/swapadd program, called during the boot process, will attempt to use anything defined as swap that is not commented. I would prefer not to comment the files as it would then be harder to tell the difference between those we wanted to use for encrypted swap and those that were commented for some other reason. To work around this issue, you simply must edit the /etc/vfstab file and define the swap device or file as something other than "swap". For the scripts discussed below, we will use the key "enc-swap". Here is an example from /etc/vfstab:

    $ grep enc-swap /etc/vfstab
    /dev/zvol/dsk/rpool/swap      -      -      enc-swap      -      no      -
    
    $ swap -l
    No swap devices configured
    

  • Remove the existing swap devices or files. It is likely that your system will have already added the swap devices or files to the system. To determine if this is the case, simply use the following command:

    $ swap -l
    swapfile                   dev    swaplo   blocks     free
    /dev/zvol/dsk/rpool/swap 182,2         8  1226744  1226744
    

    If there are devices or files already configured, remove them using the following command:

    $ pfexec swap -d /dev/zvol/dsk/rpool/swap
    
    $ swap -l
    No swap devices configured
    

    If swap is in use, you may need to reboot you system in order to remove the device at this point. Note that the previous step (where the file system type was changed to enc-swap) will ensure that the device or file is not used upon boot.)

  • Add the encrypted swap SMF service. Here is where the magic lives. You will need to download the archive containing the encrypted swap 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-swap-v0.1.tar.bz2
    
    $ bzip2 -d -c ./smf-encrypted-swap-v0.1.tar.bz2 | tar xf -
    
    $ cd ./smf-encrypted-swap
    
    $ pfexec ./install.sh
    
    $ svccfg import /var/svc/manifest/site/isc-enc-swap.xml
    

    The install.sh script is used to copy this service's SMF manifest and method scripts into the proper locations as well as set correct ownership and permissions of these files.

  • Verify the service is running and encrypted swap is configured. The last step is to verify that everything is working as expected. Use the following commands to verify the service was properly installed and enabled:

    $ svcs isc-encrypted-swap
    STATE          STIME    FMRI
    online         14:30:10 svc:/system/isc-encrypted-swap:default
    

    Use the following commands to verify that encrypted swap is in use:

    $ lofiadm
    Block Device             File                           Options
    /dev/lofi/1              /devices/pseudo/zfs@0:2c       Encrypted
    
    $ swap -l
    swapfile             dev    swaplo   blocks     free
    /dev/lofi/1         144,1         8  1226728  1226728
    

    The last two commands show that an encrypted block device was created at /dev/lofi/1 and that the device is currently in use as a swap device. It should be noted that no password, passphrase or other credential was given when the encryption was configured. This is because this service is configured to use an ephemeral key. The key is not stored on the system and is lost when the system is restarted. Upon each reboot, a new encrypted block device with a new ephemeral key will be used to configure encrypted swap.

Note that the examples above have shown the service with a single swap device, but the SMF service has been written to support multiple swap devices or files. For example, a secondary swap file could be created using the following steps:

$ pfexec zfs create -V 1G rpool/export/swapfile

$ pfexec vi /etc/vfstab
[add the new entry for rpool/export/swapfile as verified in the next step]

$ grep enc-swap /etc/vfstab
/dev/zvol/dsk/rpool/swap      -      -      enc-swap      -      no      -
/dev/zvol/dsk/rpoo/export/swapfile      -      -      enc-swap      -      no      -

$ svcadm restart isc-encrypted-swap

$ lofiadm
Block Device             File                           Options
/dev/lofi/1              /devices/pseudo/zfs@0:2c       Encrypted
/dev/lofi/2              /devices/pseudo/zfs@0:3c       Encrypted

$ swap -l
swapfile             dev    swaplo   blocks     free
/dev/lofi/1         144,1         8  1226728  1226728
/dev/lofi/2         144,2         8  2097128  2097128

There you have it! Enabling encrypted swap in OpenSolaris 2009.06 is as easy as following these few simple steps. It is worth reiterating 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 swap 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:

Friday Jun 05, 2009

Cloud Security from Sun's CommunityOne

As we come to the close of yet another week, I am reminded that this week was different. Unlike most weeks, I was actually off from work, recovering from surgery, and yet at the same time, several of my projects were living lives of their own at CommunityOne West and Java One. Since I could not be there in person to talk about this work, I figured the next best thing was to take a few moments to highlight them here and offer an open invitation to publicly discuss them on their project pages.

There were three Cloud Computing security projects that were discussed and demonstrated this week:

  • Security Hardened Virtual Machine Images.
    Summary: Sun and the Center for Internet Security have been working together for over six years to promote enterprise-class security best practices for the Solaris OS. Building upon their latest success, the Solaris 10 Security Benchmark, they have adapted its security guidance to the OpenSolaris platform and today are announcing the availability of a virtual machine image pre-configured with these settings.

    Key Points: Sun is the first commercial vendor to publish and make freely available a hardened virtual machine image - secured using industry accepted best practices. Images will be made available for both Amazon EC2 and Sun Cloud.

    More Information: Announcement.

  • Cloud Safety Box.
    Summary: Security is a key concern for customers everywhere, and the Cloud is no exception. Customers who are concerned about the confidentiality of their information should encrypt their data before sending it to the Cloud. This utility simplifies the process of encrypting files and storing them in the Cloud (as well as decrypting them after they have been retrieved).

    Key Points: The tools leverage strong, industry standard encryption (AES 256-bit) but are configurable to accommodate other algorithms and key sizes. The tools can leverage the cryptographic acceleration capabilities of systems configured with Sun's UltraSPARC T2 (Niagara 2) processor enabling ~7x speed improvement over software encryption. The tools support multiple client platforms and multiple cloud providers today including Sun Cloud and Amazon S3.

    More Information: Project Page

  • Encrypted ZFS Backups.
    Summary: Customers often encrypt their backups before sending them off-site for storage, so why should the Cloud be any different. This utility integrates with the OpenSolaris ZFS automatic snapshot service to automatically encrypt the content before storing it into the Cloud. This way, backup data is always stored in an encrypted form in the Cloud and the decryption keys never leave your organization. Recovery is as easy as downloading and decrypting the snapshots (using the Cloud Safety Box tool, for example) and reverting to those snapshots using standard ZFS methods.

    Key Points: The tool leverages strong, industry standard encryption (AES 256-bit) but is configurable to accommodate other algorithms and key sizes. The tool can leverage the cryptographic acceleration capabilities of systems configured with Sun's UltraSPARC T2 (Niagara 2) processor enabling ~7x speed improvement over software encryption. The tool supports multiple cloud providers today including Sun Cloud and Amazon S3.

    More Information: Project Page

Each of these projects were also highlighted during the Cloud Computing keynote delivered by Lew Tucker (VP/CTO, Cloud Computing) as shown in the replay, starting about 2:18 seconds into this video:

In addition, the Cloud Safety Box and ZFS Encrypted Backups projects were demonstrated at the Sun Cloud demonstrations pods and were featured prominently on both the Sun Cloud Computing landing page as well as on Project Kenai. Click the snapshots below for larger versions:

If you have not already, please give these projects a look and send me feedback! Cloud Computing security is in its infancy in many ways, and these projects are just a start down a long and winding road. I remain convinced as ever that Cloud Computing will have a role to play in raising the information security bar for everyone, but we still have work to do! As a teaser, I would say that this is just the beginning and we have quite a number of other tricks still up our sleeves! So stay tuned and send along your ideas and feedback!

Technorati Tag:

Thursday Jun 04, 2009

Free Security Hardened Virtual Machine Image

Perhaps I am a bit sensitive to the topic of security, but I could not let a "first" go by without comment. Back in 1999 and 2000, Sun was _the_ first commercial operating system vendor to publish not only detailed security guidance but also a tool that allowed organizations to harden the security configuration of their systems in accordance with Sun's best practices and their own policies. That tool, known as the Solaris Security Toolkit, continued to be enhanced and evolve for nearly a decade supporting new versions of the Solaris OS and adding new capabilities such as auditing. Recently, it has taken its next step forward as an OpenSolaris project. Best of luck to Jason (the new project leader)!

But, this was not the _first_ that compelled me to write today. Yes, there has been another!

Working together for more than six years, Sun and the Center for Internet Security have consistently collaborated on best-in-class, supportable and complete security hardening guidance for the Solaris operating system. The latest version (previously discussed), developed for the Solaris 10 operating system, was completed with substantial contributions from Sun, CIS, the U.S. National Security Agency (NSA), as well as the U.S. Defense Information Systems Agency (DISA).

Building upon this solid foundation, this week, Sun and the Center for Internet Security are proud to announce a new _first_. We have collaborated to adapt the security recommendations published in the Solaris 10 Benchmark to the OpenSolaris operating system. This alone may be an interesting _first_, but we have gone farther. We have adapted the recommendations to meet the needs of virtual machine images running in Cloud Computing environments. All of our findings and recommendations are freely available and can be found at the Sun OpenSolaris AMI Hardening Wiki. But that is not all!

We have worked with the Sun's OpenSolaris on EC2 team to develop the _first_ vendor-provided machine image that has been hardened based upon industry-accepted and vendor supported security recommendations. As a further commitment to our "Secure by Default" strategy, we have made this AMI publicly available (AMI ID: ami-35ac4a5c) so that anyone can quickly and easily make use of it without having to apply the security hardening steps manually. Interested? Learn more about this AMI from the OpenSolaris on EC2 announcement. Of course, this will also be available for the Sun Cloud too!

Special thanks to Blake Frantz (CIS), Lew Tucker (Sun), Sujeet Vasudevan (Sun), and Divyen Patel (Sun) - without whom this new _first_ would not have been possible!

Technorati Tag:

Accepted @ Cloud Computing Expo West

Back in March, I had the pleasure of presenting at Cloud Computing Expo (East) in New York City. The topic of my talk was "Enhanced Security Models for Machine Image Deployments". The abstract for this talk was:
Security is consistently rated as a leading customer concern impeding the full scale adoption of Cloud Computing. At the same time, security is viewed as complicated and painful. This session will help to ease the pain by focusing on the key issues to be considered along with specific best practices for deployment. This session will share a number of security models for IaaS machine images based upon these best practices to illustrate how we can improve upon the security state of the art in Cloud Computing today.
I had a lot of fun with this talk for a few reasons. First, it was a departure from my traditional speaking style and I certainly enjoy the challenge. Rather than inundate the audience with text, a single or small set of graphics was the presentation model of the day allowing me to weave together a story (reinforced by imagery) showing how each piece of the puzzle built upon and reinforced the overall security strategy I was discussing. The other reason it was a lot of fun was that it was a great opportunity to tie together security approaches of the past with new models such as Immutable Service Containers. We even talked about a few architectural models that could be built upon ISCs that supported more autonomic security defenses. The reception from the audience was fantasic and spawned quite a few hallway discussions allowing me to dive into the specifics not possible during the time slot allocated to the talk.

Given such a positive experience, you can see why I submitted a paper for Cloud Computing Expo) (West) when the opportunity arose. Rather than focus the talk simply on virtual machines, I decided to up-level my proposal and focus on things from an architectural perspective. Well, I am very happy to say that my proposal was accepted! So, I will be speaking at Cloud Computing Expo (West) in Santa Clara, CA on November 2nd through the 4th. I hope to see you there! As a teaser, the title of my talk will be "Cloud Security - It's Nothing New; It Changes Everything!". The abstract goes as follows:

This session cuts through the hype and sharpens our focus on what security means for cloud computing and and other elastic, hyper-scale architectures. Is security different in the Cloud? If so, how and for what types of clouds? Is it time to challenge some of our existing ideas and practices? There has been much discussion about security being a barrier to Cloud adoption, but where do we really stand today? This session will examine Cloud security including threats, new challenges and opportunities. Concepts will be reinforced using use cases and architectural patterns showing why cloud computing has the potential to help enable security like never before! Come join the revolution. Cloud security is nothing new, and it changes everything!
Hope to see you there!

Technorati Tag:

Friday May 01, 2009

Cloud Safety Box

Yesterday, I wrote about the ZFS Encrypted Backup to S3 project that I started over at Project Kenai. This project integrates with the ZFS Automatic Snapshot service to provide a way for automatically storing encrypted ZFS snapshots into the Cloud.

So, what if you wanted to just store and retrieve individual files? Well, there is a tool to help fill this need as well! The Crypto Front End to S3 CLIs project offers a couple tools that allow you to encrypt and upload files to the Cloud (and of course download and decrypt files as well). This project provides a very simple to use interface in the form of the Cloud Safety Box, a tool that leverages a number of pre-configured default settings to trade-off flexibility for ease of use. For those wanting more control over the settings (including encryption provider, encryption algorithm, key type and other settings), simply use the s3-crypto.sh utility. A diagram is available showing how these tools work together.

Since these tools can be configured to use OpenSSL as their cryptography provider (and there are no further dependencies on OpenSolaris, you can actually use this tool on other operating systems (e.g., Mac OS X was successfully used during one of the tests).

It should be noted that the s3-crypto.sh utility can be used to download and decrypt an ZFS snapshot uploaded to the Cloud using the ZFS Encrypted Backup to S3 utility so that with these two tools you have a way of storing and retrieving regular files as well as ZFS snapshots.

You can find all of the details, documentation and download instructions (as well as a Mercurial gate) at the Crypto Front End to S3 CLIs project page. So, please give it a try and let us know what you think!

Technorati Tag:

Thursday Apr 30, 2009

Saving Encrypted ZFS Snapshots to the Cloud

Are you an OpenSolaris user? Do you use ZFS? Have you tried the ZFS Automatic Snapshot service? If so, you might be interested in a new tool that I just published over at Project Kenai that enables you to encrypt and store ZFS snapshots to either the Sun Cloud Storage Service (Employees Only at the moment) or Amazon's Simple Storage Service (S3).

You can find all of the details, documentation and download instructions (as well as a Mercurial gate) at the ZFS Encrypted Backup to S3 project page. So, please give it a try and let us know what you think!

Technorati Tag:

Monday Mar 09, 2009

NEW: Solaris Package Companion v0.9

Today, I am proud to announce the release of version 0.9 of the Solaris Package Companion. This new version is primary based upon a set of patches provided by Jerome Blanchet that provided support for the collection and processing of reverse dependency information ("R" entries in a package's depend(4)) file) as well as enhanced processing and display of platform specific packages. Thank you, Jerome!

As is my tradition when a bug is found, I try and publish a little something extra as a mea cupla. Due to limited "free time", the "mea culpa" enhancement this time is quite minor but worth mentioning anyway. In past versions, there was no interface to change the information collection rules of the tool. If you wanted to disable the collection of certain types of information (such as package names or dependencies) you had to go into the code and change the relevent COLLECT_ variable. No longer. The defaults are still the same, but now the tool will honor variable settings originating from the shell or command line as follows:

$ env COLLECT_NAMES=0 ./spc-v0.9.ksh -r /tmp/myrepository -i -l

Note that the COLLECT_ variables are only used during the creation of a repository. Not a big enhancement, but one none the less! Thank you again Jerome for discovering the bug and offering a patch!

Keep the suggestions, reports and fixes coming!

Glenn

Technorati Tag:

Friday Feb 13, 2009

Solaris Security Chat in SecondLife

Virtual Glenn is a pretty strange concept, but for those who can move past it, check this out! This is a picture of my SecondLife avatar in front of the Solaris Campus stage. On February 24th, 2009 at 9 AM PT / 12 PM ET, I will be participating in an expert chat that will be loosely based around my blog article titled Top 5 Solaris 10 Security Features You Should Be Using. I will be talking a bit about each of the five items as well as answering questions. In total, the event will last about an hour and should be a lot of fun (assuming I can overcome being a SecondLife n00b!)

This will be my first presentation inside of a virtual world, and I would encourage anyone who is interested to get a login, a copy of the client, and join me on the 24th to have a little fun a world away. For more information, check out the Sun Virtual Worlds posting for the event! Hope to see you there!

Wednesday Jan 28, 2009

Amazon S3 Silent Data Corruption

While catching up on my reading, I came across an interesting article focused on the Amazon's Simple Storage Service (S3). The author points to a number of complaints where Amazon S3 customers had experienced silent data corruption. The author recommends calculating MD5 digital fingerprints of files before posting them to S3 and validating those fingerprints after later retrieving them from the service. More recently, Amazon has posted a best practices document for using S3 that includes:

Amazon S3’s REST PUT operation provides the ability to specify an MD5 checksum (http://en.wikipedia.org/wiki/Checksum) for the data being sent to S3. When the request arrives at S3, an MD5 checksum will be recalculated for the object data received and compared to the provided MD5 checksum. If there’s a mismatch, the PUT will be failed, preventing data that was corrupted on the wire from being written into S3. At that point, you can retry the PUT.

MD5 checksums are also returned in the response to REST GET requests and may be used client-side to ensure that the data returned by the GET wasn’t corrupted in transit. If you need to ensure that values returned by a GET request are byte-for-byte what was stored in the service, calculate the returned value’s MD5 checksum and compare it to the checksum returned along with the value by the service.

All in all - good advice, but it strikes me as unnecessarily "left as an exercise to the reader". Just as ZFS has revolutionized end-to-end data integrity within a single system, why can't we have similar protections at the Cloud level? While certainly it would help if Amazon was using ZFS on Amber Road as their storage back-end, even this would be insufficient...

Clearly, more is needed. For example, would it make sense to have an API layer be added that automates the calculation and validation of digital fingerprints? Most people don't think about silent data corruption and honestly they shouldn't have to! Integrity checks like these should be automated just as they are in ZFS and TCP/IP! As we move into 2009, we need to offer easy to use, approachable solutions to these problems, because if the future is in the clouds, it will revolve around the data.

Technorati Tag:

About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today