4 ms·

The big thing missing from the OSS implementations that Oracle 11 has got is FDE. It's possible with dmcrypt and LUKS, but you void most of the reasons for usi

The big thing missing from the OSS implementations that Oracle 11 has got is FDE. It's possible with dmcrypt and LUKS, but you void most of the reasons for using ZFS. encryptFS is also a possibility, but it's both much less secure (an attacker can run ls) and also drops a few ZFS features like dedup. Meanwhile, Solaris 11 has FDE that actually works, and there seems to be no serious FOSS effort either to reverse engineer their work, or to design something better. In 2013, no software developer should be storing things without FDE unless they have unusual physical security measures. That makes FOSS ZFS a non-starter for most of the people who would use it.

glabifrons 14y ago
Filesystem encryption is very handy for a notebook computer (I use it, myself), but in a datacenter it's value is a bit more questionable. Where do you store your encryption keys? If they're on a removable USB device (for example), you'd have to contact the datacenter personnel to plug them in in the event you had to reboot (which happens from time to time if you perform OS SRU uprades). If the USB device is left in the server and someone gains privileged access to the machine, they've got the key as well as the data. If the USB device is not in the server and someone gains privileged access to the machine, they still have access to the data. The only time disk encryption is valuable is when the machine is off or the disks are being transported.
- drewcrawford 14y ago
  > The only time disk encryption is valuable is when the machine is off or the disks are being transported. I'm thinking about the case where you have a computer in the home or office environment, e.g. the burglary attack vector. It's not just notebooks that get stolen. I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents. In this case you are typing the keys in on boot, and you either ignore the RAM extraction attacks (which are difficult to execute in practice for non-academic attackers) or you can mitigate them by storing in L1 cache and so on. Datacenters have unusually high physical security, and in addition I don't generally store highly sensitive data there (my work doesn't involve PCI compliance etc.) Whereas I do have PCI-level data about myself on my own computers.
  - glabifrons 14y ago
    "It's not just notebooks that get stolen." Very good point. I guess I've been working in environments with datacenters too long. :) "I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents." Again though, that only protects you if the disks are out or the machine is down. If you have someone with that level of skill within your organization, they'll likely gain access to the running computer where the data has already been made accessible in decrypted form.
roto 14y ago
FDE Is exactly why my home FS is Solaris 11 (32gb / AES-NI capable xeon). Linux ZFS + their encryption layers combined with large file preallocations performs very poorly. Its too bad, i really dislike Oracle, but its the best tool for the job currently. And for the person above, as long as you restrict the pool version to 28 when creating under solaris 11 you can still migrate between solaris/linux/bsd. Obviously you lose out on native FDE though.

glabifrons 14y ago

Filesystem encryption is very handy for a notebook computer (I use it, myself), but in a datacenter it's value is a bit more questionable. Where do you store your encryption keys? If they're on a removable USB device (for example), you'd have to contact the datacenter personnel to plug them in in the event you had to reboot (which happens from time to time if you perform OS SRU uprades). If the USB device is left in the server and someone gains privileged access to the machine, they've got the key as well as the data. If the USB device is not in the server and someone gains privileged access to the machine, they still have access to the data. The only time disk encryption is valuable is when the machine is off or the disks are being transported.

drewcrawford 14y ago
> The only time disk encryption is valuable is when the machine is off or the disks are being transported. I'm thinking about the case where you have a computer in the home or office environment, e.g. the burglary attack vector. It's not just notebooks that get stolen. I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents. In this case you are typing the keys in on boot, and you either ignore the RAM extraction attacks (which are difficult to execute in practice for non-academic attackers) or you can mitigate them by storing in L1 cache and so on. Datacenters have unusually high physical security, and in addition I don't generally store highly sensitive data there (my work doesn't involve PCI compliance etc.) Whereas I do have PCI-level data about myself on my own computers.
- glabifrons 14y ago
  "It's not just notebooks that get stolen." Very good point. I guess I've been working in environments with datacenters too long. :) "I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents." Again though, that only protects you if the disks are out or the machine is down. If you have someone with that level of skill within your organization, they'll likely gain access to the running computer where the data has already been made accessible in decrypted form.

roto 14y ago

FDE Is exactly why my home FS is Solaris 11 (32gb / AES-NI capable xeon). Linux ZFS + their encryption layers combined with large file preallocations performs very poorly. Its too bad, i really dislike Oracle, but its the best tool for the job currently. And for the person above, as long as you restrict the pool version to 28 when creating under solaris 11 you can still migrate between solaris/linux/bsd. Obviously you lose out on native FDE though.