Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted file 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. pgprO3IdicpgH.pgp Description: PGP signature ___ 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 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) > or by a user for some other reason. The auditors don't want to rely on > processes being followed by people to ensure security (and I agree with > them). They like a nice straight-forward story - "the whole system is > encrypted". > > So, answering your question, I don't want the OS encrypted, I want all > writable media encrypted. > > In terms of the two factors, I think I should: 1) need a physical thing > (e.g. a usb stick with a particular file on it) and, 2) know a > password/passphrase, in order to be able to boot the system. (The usb stick > can be removed once authentication is completed.) > > Although the mobility of the usage sounds rather more "laptop" than "data > centre", the systems are used for collecting and storing terabytes of data > (at rates up to 10 Gb/s), so the scale quickly becomes more like data > centre. And back to the earlier point, the data storage can be on zfs > encrypted fs's, it's just a case of closing the last loophole. Additionally, > some of the data reports generated can be quite small (easily fit on the > system disk) and still require protection in the event of lost disks. > > In a lights out situation, presuming the trusted location, the usb stick > could be left in the machine and passphrases supplied at boot time. It might > also be possible to arrange a passphrase server with ssh/asymmetric > encryption to supply the passphrase during boot, using the booting system's > public key and including replay prevention. This approach might address the > high availability (HA) scenario, but I'm afraid I don't have any experience > of HA systems. > > I appreciate that this type of two factor booting will require some > management overhead, usb sticks will need labels and tracking, and keys and > passphrases will need storing/backing up. These will add cost but, "security > costs". > > I hope this gives you a better idea of what I need. > > Regards, > Rob > > > PSs > > Writable media and the OS - Booting and operating from a read-only DVD and > using memory backed caching for everything, sounds good in theory. However, > this would be a total pain whenever you need to make a permanent change to a > system setting, as you then need to burn another DVD and reboot the system. > Unless you were going into mass production with 10s of identical systems, I > don't think this would be a usable solution. > > Limiting authentication attempts - It might be a good thing to obliterate, > after say 20 attempts, the on-system data which is used to release the key, > forcing the need to access a backup of that data. I think this would slow > down a good-guesses/dictionary style attack by a person at the keyboard but > may not be effective against a determined attacker who makes images of the > disk before starting... I'm sure you know more about this than I do. > > -Original Message- > From: Darren J Moffat [mailto:darr...@opensolaris.org] > Sent: 26 April 2011 09:47 > 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 > > > On 24/04/2011 18:49, Rob O'Leary wrote: >> Reading this reminded me that the feature I'm really waitin
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) > or by a user for some other reason. The auditors don't want to rely on > processes being followed by people to ensure security (and I agree with > them). They like a nice straight-forward story - "the whole system is > encrypted". > > So, answering your question, I don't want the OS encrypted, I want all > writable media encrypted. > > In terms of the two factors, I think I should: 1) need a physical thing > (e.g. a usb stick with a particular file on it) and, 2) know a > password/passphrase, in order to be able to boot the system. (The usb stick > can be removed once authentication is completed.) > > Although the mobility of the usage sounds rather more "laptop" than "data > centre", the systems are used for collecting and storing terabytes of data > (at rates up to 10 Gb/s), so the scale quickly becomes more like data > centre. And back to the earlier point, the data storage can be on zfs > encrypted fs's, it's just a case of closing the last loophole. Additionally, > some of the data reports generated can be quite small (easily fit on the > system disk) and still require protection in the event of lost disks. > > In a lights out situation, presuming the trusted location, the usb stick > could be left in the machine and passphrases supplied at boot time. It might > also be possible to arrange a passphrase server with ssh/asymmetric > encryption to supply the passphrase during boot, using the booting system's > public key and including replay prevention. This approach might address the > high availability (HA) scenario, but I'm afraid I don't have any experience > of HA systems. > > I appreciate that this type of two factor booting will require some > management overhead, usb sticks will need labels and tracking, and keys and > passphrases will need storing/backing up. These will add cost but, "security > costs". > > I hope this gives you a better idea of what I need. > > Regards, > Rob > > > PS
RE: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed
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) or by a user for some other reason. The auditors don't want to rely on processes being followed by people to ensure security (and I agree with them). They like a nice straight-forward story - "the whole system is encrypted". So, answering your question, I don't want the OS encrypted, I want all writable media encrypted. In terms of the two factors, I think I should: 1) need a physical thing (e.g. a usb stick with a particular file on it) and, 2) know a password/passphrase, in order to be able to boot the system. (The usb stick can be removed once authentication is completed.) Although the mobility of the usage sounds rather more "laptop" than "data centre", the systems are used for collecting and storing terabytes of data (at rates up to 10 Gb/s), so the scale quickly becomes more like data centre. And back to the earlier point, the data storage can be on zfs encrypted fs's, it's just a case of closing the last loophole. Additionally, some of the data reports generated can be quite small (easily fit on the system disk) and still require protection in the event of lost disks. In a lights out situation, presuming the trusted location, the usb stick could be left in the machine and passphrases supplied at boot time. It might also be possible to arrange a passphrase server with ssh/asymmetric encryption to supply the passphrase during boot, using the booting system's public key and including replay prevention. This approach might address the high availability (HA) scenario, but I'm afraid I don't have any experience of HA systems. I appreciate that this type of two factor booting will require some management overhead, usb sticks will need labels and tracking, and keys and passphrases will need storing/backing up. These will add cost but, "security costs". I hope this gives you a better idea of what I need. Regards, Rob PSs Writable media and the OS - Booting and operating from a read-only DVD and using memory backed caching for everything, sounds good in theory. However, this would be a total pain whenever you need to make a permanent change to a system setting, as you then need to burn another DVD and reboot the system. Unless you were going into mass production with 10s of identical systems, I don't think this would be a usable solution. Limiting authentication attempts - It might be a good thing to obliterate, after say 20 attempts, the on-system data which is used to release the key, forcing the need to access a backup of that data. I think this would slow down a good-guesses/dictionary style attack by a person at the keyboard but may not be effective against a determined attacker who makes images of the disk before starting... I'm sure you know more about this than I do. -Original Message- From: Darren J Moffat [mailto:darr...@opensolaris.org] Sent: 26 April 2011 09:47 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 On 24/04/2011 18:49, Rob O'Leary wrote: > Reading this reminded me that the feature I'm really waiting for is > two-factor boot time authentication from encrpyted zfs boot... Can you explain more about your requirements and use case ? Is this "laptop" or "data centre" ? or some thing else ? What "two factors" do you want ? How will this work in a lights out and/or high availability deployment ? Why do you want the operating system itself encrypted rather than just the data stored on the system ? ie What is threat you are trying to protect against ? > Is this likely to be seen in the near-ish future? I need to know more about what you mean before I can determine that. -- 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 encrypted file system at boot? Why no pass phraserequesed
On 24/04/2011 18:49, Rob O'Leary wrote: Reading this reminded me that the feature I'm really waiting for is two-factor boot time authentication from encrpyted zfs boot... Can you explain more about your requirements and use case ? Is this "laptop" or "data centre" ? or some thing else ? What "two factors" do you want ? How will this work in a lights out and/or high availability deployment ? Why do you want the operating system itself encrypted rather than just the data stored on the system ? ie What is threat you are trying to protect against ? Is this likely to be seen in the near-ish future? I need to know more about what you mean before I can determine that. -- Darren J Moffat ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed
Reading this reminded me that the feature I'm really waiting for is two-factor boot time authentication from encrpyted zfs boot... Is this likely to be seen in the near-ish future? Regards Rob -Original Message- From: zfs-crypto-discuss-boun...@opensolaris.org [mailto:zfs-crypto-discuss-boun...@opensolaris.org]On Behalf Of Darren J Moffat Sent: 21 April 2011 13:32 To: Dr. David Kirkby Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: How to mount encrypted file system at boot? Why no pass phraserequesed On 21/04/2011 11:05, Dr. David Kirkby wrote: > I went to a talk last night at the London Open Solaris User Group (LOSUG) by Darren Moffat - an Oracle engineer who had a major role in the ZFS encryption implementation in Solaris. I was particularly interested in this,as for a long time I've been concerned about security of data on my laptop. > > I decided to try to secure my laptop, which is running Solaris 11 Express. I want to set the machine up so that during the boot process I get asked to enter the pass phrase to mount file system with my home directory on. > > But I am having problems. > > First I create the file system. As expected, Solaris asks for a pass phrase: > > drkirkby@laptop:~# zfs create -o compression=on -o encryption=on -o > mountpoint=/export/home/davek rpool/export/home/davek > Enter passphrase for 'rpool/export/home/davek': *** > Enter again: ** > > Next I create a file on the file system and check it exists. > > drkirkby@laptop:~# touch /export/home/davek/foo > drkirkby@laptop:~# ls /export/home/davek/foo > /export/home/davek/foo > > Unmount the encrypted file system > > drkirkby@laptop:~# zfs umount rpool/export/home/davek > > Check the file I created is no longer available > > drkirkby@laptop:~# ls /export/home/davek/foo > /export/home/davek/foo: No such file or directory > Now I get a problem. I was expecting to have to enter the pass > phrase again when attempting to mount the file system, but this is not being > requested. As you can see, I can mount the file system without the pass > phrase and read the data on the file system. I covered that in the talk last night - in fact we had about a 5 minute discussion about why it is this way. If you want the key to go away you need to run: # zfs key -u rpool/export/home/davek > drkirkby@laptop:~# zfs mount rpool/export/home/davek > drkirkby@laptop:~# ls /export/home/davek/foo > /export/home/davek/foo > drkirkby@laptop:~# > > This looks wrong to me, but I've no idea how to solve it. No it is correct by design. As I mentioned last night the reason for this is so that delegated administration of certain properties can work for users that don't have the 'key' delegation and don't have access to the wrapping keys. For example changing a mountpoint causes an umount followed by a mount. There are other changes that under the covers can cause a filesystem to be temporarily unmounted and remounted. > The next issue is how do I get the file system to mount when the > machine is booted? I want to supply the pass phrase by typing it in, > rather than from storing it in USB stick or other similar method. Since this is your user home directory the ideal way would be a PAM module that ran during user login and requested the passphrase for the ZFS encrypted home dir. There isn't one in Solaris 11 Express (snv_151a) at this time. > Any ideas what I need to do to get this file system to request the > pass phrase before mountin g the file system? There is source for a prototype PAM module in the old opensolaris.org zfs-crypto repository: http://src.opensolaris.org/source/history/zfs-crypto/phase2/usr/src/lib/pam_ modules/ You would need to take a clone of that repository and check out changeset 6749:6dded109490e and see if that old PAM module could be hacked into submission. Note that it uses private interfaces and doing so is not supported by any Oracle support contract you have. -- Darren J Moffat ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
