Wednesday Nov 04, 2009

NEW: Solaris 10 Security Deep Dive Presentation

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!


Technorati Tag:

Thursday Jul 09, 2009

Encrypted ZFS using Amazon EBS and OpenSolaris 2009.06

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:

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".

# 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.

# 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_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.

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:

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
    $ bzip2 -d -c ./smf-encrypted-scratch-v0.1.tar.bz2 | tar xf -
    $ cd ./smf-encrypted-scratch
    $ pfexec ./
    $ 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
    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
            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
            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-\*
    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

  • (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
    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

    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 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:


This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.


« June 2016