Encrypted Scratch Space in OpenSolaris 2009.06
By gbrunett on Jun 12, 2009
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!
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!