RE: ZFS crypto source
I guessed you wouldn't be able to say, even if... The only shortfall in capability that I'm aware of is the secure boot/FDE, which we discussed previously. I am mostly interested in the source to see how features have been implemented and to understand the system structure. I certainly wouldn't presume to make changes! On the slightly more general topic of source on opensolaris, are the designs for subsystems/features available? I've found PSARC cases for some things but I expect that more detailed design, system interaction and use cases are documented as part of the development process. Are any of these types of document made public to assist in understanding at a higher level than the source code? Again, this is really to help me understand the system, rather than to attempt any modification. Regards Rob -Original Message- From: Darren J Moffat [mailto:darr...@opensolaris.org] Sent: 10 May 2011 11:17 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: ZFS crypto source On 07/05/2011 10:57, Rob O'Leary wrote: Is the source for ZFS crypto likely to be released on opensolaris.org? Older versions of the source area available from the zfs-crypto project gates: /zfs-crypto/gate/ However in some important areas these differ quite a bit from what was finally integrated and are not on disk compatible. I searched in /onnv/onnv-gate/usr/src/uts/common/fs/zfs, which may have been the wrong place, for aes and crypt and got no results so I assume that the zfs encryption has not been released to date. Correct the source has not been released. I do not know anything about future plans nor would I be able to comment here at this time even if I did. Please bring this up with your Oracle account/support team representative if it is important to your business. Is there something in particular you want to do with the source if you had it available to you ? Are there changes you want to make ? -- Darren J Moffat ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
RE: Booting from encrypted ZFS WAS: RE: How to mount encryptedfile system at boot? Why no pass phraserequesed
Hi Dan, Your first two interpretations are correct. I like the idea of netbooting but unfortunately, although a good idea, it doesn't fit with the details of our use case - we temporarily take our system to a trusted location, use it and then remove it, so we do not have a permanent presence at the trusted locations (other than our base location). This means that providing the netboot environment is effectively the same problem, as anything on the same network as the data becomes subject to the same rules regarding protection. Putting the boot system on the key media isn't quite the same as transporting the key on media alone - the key media can be read-only/only used at boot to authenticate, whereas the boot system is on writable media. (I have already considered read-only boot images on DVD but due to the low numbers of systems and the need to make permanent changes to the system, I do not consider this approach operable.) Regarding tampering and tamper detection, when the disks are transported, we do not rely on an IT approach to these issues. Regards, Rob -Original Message- From: Daniel Carosone [mailto:d...@geek.com.au] Sent: 28 April 2011 03:21 To: Rob O'Leary Cc: Troels N?rgaard Nielsen; zfs-crypto-discuss@opensolaris.org Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encryptedfile system at boot? Why no pass phraserequesed If I understood correctly: - there is no requirement for the system to boot (or be bootable) outside of your secure locations. - you are willing to accept separate tracking and tagging of removable media, e.g. for key distribution. Consider, at least for purposes of learning from the comparison: - having the machines netboot only, and provide the netboot environment only within the secure locations. - having the system disks on the removable media that is handled separately, not just the keys. Both of these share the property that the physical chassis being transported contains only encrypted disks, leaving you to make other tradeoffs with respect to risks and handling of the bootstrapping data (including keys). My primary interest in encrypted zfs boot for the OS is more around the integrity of the boot media, for devices that may be exposed to tampering of various kinds. This is a complex issue that can only be partly addressed by ZFS, even with such additional features. Do these sorts of concerns apply to your environment? If someone was to intercept one of these machines in transit, and tamper with OS and system executables in such a way as to disclose information/keys or otherwise alter their operation when next booted in the secure environment, would that be a concern? -- Dan. ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
RE: Booting from encrypted ZFS WAS: RE: How to mount encrypted filesystem at boot? Why no pass phraserequesed
Hi Michel, I had noticed these drives in the past, but your email reminded me and I followed your link, thanks. A bit of googling showed that not everyone is having a great experience and I couldn't find the barracuda fde promised in the press release. I also need SAS because of read while writing issues and these are momentus sata disks (despite link names below). Can I mix sas and sata in the same controller? Reliable, SAS, FDE does not seem to be available... Regards, Rob http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Issues-with-ST932032 2AS-FDE-3-drives/m-p/29247#M12876 http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Recovering-Formattin g-FDE-Drives/td-p/7412 -Original Message- From: michel.bell...@malaiwah.com [mailto:michel.bell...@malaiwah.com] Sent: 27 April 2011 12:08 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted filesystem at boot? Why no pass phraserequesed Hi, I think the best solution for your OS drives is to have a look at disks that offer built-in full disk encryption (FDE) just like the ones offered by Seagate (example: http://www.google.com/url?q=http://www.seagate.com/ww/v/index.jsp%3Flocale%3 Den-US%26name%3Ddn_sec_intro_fde%26vgnextoid%3D1831bb5f5ed93110VgnVCM10f 5ee0a0aRCRDsa=Uei=8_e3TfvVIInBtgemsdjeBAved=0CAgQFjAAusg=AFQjCNGt_c3Vokq 4D6hL8k25rfUcIrB2Bw). While it does not offer the flexibility of ZFS encrypted datasets, I think it would be appropriate in your situation. I would rely on that encryption for the OS with a static passphrase asked at boot-time, but still point sensitive informations to the ZFS pool for better management of the keys, if your auditor asks them to be rolled once in a while (for data, at least). My 2 cents, Michel Envoyé de mon terminal mobile BlackBerry par le biais du réseau de Rogers Sans-fil -Original Message- From: Rob O'Leary raole...@btinternet.com Sender: zfs-crypto-discuss-boun...@opensolaris.org Date: Wed, 27 Apr 2011 11:46:02 To: Troels Nørgaard Nielsentro...@norgaard.co Cc: zfs-crypto-discuss@opensolaris.org Subject: RE: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed Hi Troels, There are two things here. First, I don't want to learn another set of administration tasks (I've just had a quick look at Trusted Extensions and am shuddering at the thought) and second, the problem isn't when the system is running but when it is stopped. I believe the problem is called data at rest. Also, notice the line where I said the auditors like a simple story. They really do. I still want to be able to print and use the network without incurring lots of admin, re-programming or performance overhead. (Our applications are very network heavy.) But, when I shutdown I want the data on the disks to be un-intelligible. In terms of management/learning overhead, we are very familiar with tracking and accounting for documents and keys, so having a few extra keys and usb sticks to look after is no problem. Unfortunately, I don't know enough about grub and zfs booting. So, I shall resist the temptation of can't it just Almost. I'm sure there's a way. Chain from authentication phase and getting key to main boot...? (Sorry, I had to.) Best regards, Rob -Original Message- From: Troels Nørgaard Nielsen [mailto:tro...@norgaard.co] Sent: 27 April 2011 11:13 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed Hi Rob, Wouldn't the use of Solaris Trusted Extensions by placing all 'secure' operations inside a label that can only write to the filesystem (that is encrypted) with the same label, do for you what the auditors are seeking? The base idea of Trusted Extensions is that no data can escape it's label (guarded by syscall checks), to ensure traffic to the label, one can use IPSec with labeling, etc. I think Darren is dragging along here, because implementing zfs-crypto on rpool requires grub to be aware of zfs-crypto, which is kinda hard (e.g. grub doesn't support multiple vdev or raidz-n yet). Best regards Troels Nørgaard Nørgaard Consultancy Den 27/04/2011 kl. 09.54 skrev Rob O'Leary: Requirements The main requirement is to convince our security auditors that all the data on our systems is encrypted. The systems are moved between multiple trusted locations and the principle need is to ensure that, if lost or stolen while on the move, no data can be accessed. The systems are not required to operate except in a trusted location. Storing the data on encrypted zfs filesystems seems like it should be sufficient for this. But the counter argument is that you cannot _guarentee_ that no data will be accidentally copied onto un-encrypted parts of the system, say as part of the print spooling of a data report (by the system
