> On Mar 14, 2015, at 6:56 PM, Tim Boudreau via smartos-discuss
> <[email protected]> wrote:
>
> At the risk of sounding like an ignoramus: In a *server* OS, what exactly is
> gained by encryption? Unless the plan is someone physically sitting at the
> console to type in the decryption key (for every zone??) on every boot, the
> machine needs to have the decryption key accessible at runtime to function.
> Which makes the whole enterprise a bit like buying a fabulously secure lock
> for your house that you have to leave the key in at all times or the house
> falls down - why bother?
>
> I get that people think it buys them something, or may be required to do it
> by someone who does. But is that anything more than an illusion? I mean,
> yes, it could live on the USB key and if the server is off someone can take
> the key away and the data on the disks is not decryptable if someone walks
> off with the server. But under what circumstances is that useful?
In a nutshell, it really isn’t, with ordinary hardware, unless you’re willing
to completely forgo any hope of automated reboot. (Which normally precludes
server use.)
With custom hardware and software, it is possible to arrange for the keying
material to live inside a custom TPM (or a similar module) such that the key
material is protected somewhere where it can’t be used, and it can only be used
to decrypt a particular file as part of a boot flow. This is atypical of most
solutions.
In a server setting, a bigger concern is usually theft of disk drives (someone
walking down the data center yanks some drives), or ensuring that data on
drives is not usable after drives are retired (perhaps returned due to service,
etc.)
In those situations, a better solution is the use of self-encrypting drives,
combined with suitable firmware & HBAs. The BIOS and HBAs work together to
make sure that the disks are encrypted in a way that makes them unusable
outside of the server chassis where they were set up. This avoids most of the
concerns. It does present other problems; for example if your HBA or chassis
needs replacement, you better have backups (or at least a backup of the
password used to generate the key if a password-based-key scheme was used, as I
*suspect* is probably the case.) Also these configurations are likely to be
difficult or impossible to use in a shared storage cluster unless you can
arrange for all members of the cluster to have the same keys. (Again,
password-based-keying works well here, but check with your vendors.) The real
beauty of these solutions is that they generally have close to zero performance
impact (the encryption is performed by an asic in the drive usually), and zero
software impact for operating systems and applications.
- Garrett
>
> -Tim
>
>
> On Sat, Mar 14, 2015 at 8:11 PM, Richard Elling via smartos-discuss
> <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Mar 14, 2015, at 2:08 PM, Jonathan Paget via smartos-discuss
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> >> Are there any encryption options?
>>
>> Your only real option is for a KVM guest to use encryption inside a Zone
>> (CentOS and Ubuntu offer encryption at their install screens). Some people
>> use ZVOLs as back-ends for FreeBSD's GELI on FreeBSD, or use GELI to encrypt
>> the underlying vdevs of their zpool, but FreeBSD Jails aren't anywhere near
>> a complete alternative to zones.
>
> lofi on SmartOS, managed with the lofiadm command. There would be some
> assembly required, but shouldn't need any new code.
> -- richard
>
>>
>> If you need to run Windows guests, you could probably find a way to PXE-boot
>> them off of iSCSI targets (running in another Zone) that have encrypted
>> back-ends or just have them use Samba to access encrypted volumes.
>>
>>
>> Yes I understand everything I typed above is very ugly. I would really
>> like to see encrypted added to the illumos/ZFS or OpenZFS feature set, would
>> do it myself if I currently held the necessary skillset.
>>
>>
>> On Sat, Mar 14, 2015 at 2:00 PM, George Linn via smartos-discuss
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>> Are there any encryption options? Specifically if the SmartOS installation
>> is used primarily for hosting Zones. Could sleep better knowing that if my
>> machine was physically compromised my data would be a bit more difficult to
>> access.
>>
>> From: Brian Bennett via smartos-discuss <[email protected]
>> <mailto:[email protected]>>
>> To: [email protected]
>> <mailto:[email protected]>; George Linn
>> <[email protected] <mailto:[email protected]>>
>> Sent: Saturday, March 14, 2015 4:29 PM
>> Subject: Re: [smartos-discuss] ZFS encryption
>>
>> ZFS encryption was integrated into Solaris 11 after OpenSolaris updates
>> stopped. That's not to say it couldn't be added, but it hasn't been a
>> priority so far.
>>
>> --
>> Brian Bennett
>> Systems Engineer, Cloud Operations, Joyent, Inc.
>> 655 Montgomery St., Suite 1600 | San Francisco | California | 94111
>> [email protected] <mailto:[email protected]> | www.joyent.com
>> <http://www.joyent.com/>
>> office 415-400-0645 <tel:415-400-0645> | mobile 619-663-IPv6
>>
>>
>>
>>> On Mar 14, 2015, at 11:17 AM, George Linn via smartos-discuss
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> After some searching, it seems that there is no integrated encryption for
>>> ZFS in SmartOS that would allow something like the following to happen:
>>>
>>> zfs create -o encryption=on rpool/export/somthing
>>>
>>> Can encryption be used with ZFS at all on SmartOS? I see some examples of
>>> creating encrypted block devices in OpenIndiana but I am not sure how this
>>> is helpful in a general sense on SmartOS since my disk space is all
>>> allocated during the initial installation of SmartOS.
>>>
>>>
>>> smartos-discuss | Archives
>>> <https://www.listbox.com/member/archive/184463/=now>
>>> <https://www.listbox.com/member/archive/rss/184463/26986985-d0246faa> |
>>> Modify <https://www.listbox.com/member/?&;> Your Subscription
>>> <http://www.listbox.com/>
>>
>>
>>
>>
>>
>> -------------------------------------------
>> smartos-discuss
>> Archives: https://www.listbox.com/member/archive/184463/=now
>> <https://www.listbox.com/member/archive/184463/=now>
>> RSS Feed:
>> https://www.listbox.com/member/archive/rss/184463/26967883-1315225c
>> <https://www.listbox.com/member/archive/rss/184463/26967883-1315225c>
>> Modify Your Subscription: https://www.listbox.com/member/?&;
>> <https://www.listbox.com/member/?&;>
>> Powered by Listbox: http://www.listbox.com <http://www.listbox.com/>
>>
>> smartos-discuss | Archives
>> <https://www.listbox.com/member/archive/184463/=now>
>> <https://www.listbox.com/member/archive/rss/184463/26912851-a47b45cc> |
>> Modify <https://www.listbox.com/member/?&;> Your Subscription
>> <http://www.listbox.com/>
>> smartos-discuss | Archives
>> <https://www.listbox.com/member/archive/184463/=now>
>> <https://www.listbox.com/member/archive/rss/184463/21953302-fd56db47> |
>> Modify <https://www.listbox.com/member/?&;> Your Subscription
>> <http://www.listbox.com/>
> smartos-discuss | Archives
> <https://www.listbox.com/member/archive/184463/=now>
> <https://www.listbox.com/member/archive/rss/184463/24549504-c4bff9d3> |
> Modify <https://www.listbox.com/member/?&;> Your Subscription
> <http://www.listbox.com/>
>
>
> --
> http://timboudreau.com <http://timboudreau.com/>
> smartos-discuss | Archives
> <https://www.listbox.com/member/archive/184463/=now>
> <https://www.listbox.com/member/archive/rss/184463/22103350-51080293> |
> Modify <https://www.listbox.com/member/?&;> Your Subscription
> <http://www.listbox.com/>
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
