Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 23/06/2006 Florian Weimer wrote: the only cases that are known to me, where data loss may still occur are encrypted devices without an identifying header, like plain dm-crypt devices. Logical volumes are in this category, too. how? if they don't contain any data? i don't talk about partition types here, but about the data on the device. and logical volumes don't differ from other devices here. i don't like the idea to check for string 'swap' in the source or target device, as this would enforce even more restrictions to the admin. Currently, it does not work at all. How could soemthing else be more restrictive? the current situation is broken. it was never intended to deny encrypted swap. the discussion is not about a fix for the current situation but about a better checksystem implementation in general. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 21/06/2006 Andrew Pimlott wrote: first, LUKS devices with random key are possible, you just need to store the random key after luksFormat, to reuse it for luksOpen. afterwards you can shred/wipe the key. True, but this can't be configured in crypttab, which makes it effectively unavailable. Moreover, it wouldn't provide much additional safety. Presumably, a hypothetical luksrandom keyword in crypttab would mean: check that it's a luks partition, than re-luksFormat and luksOpen with the same random key. The problem is, this would happily trash any normal (non-randomly-keyed) luks partition. So you really want an explicit marker that says I am disposable. do you see any advantages in providing this? i don't like the idea of invoking luksFormat automatically in any case. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. yes, that's exactly what i suggested as well. in my opinion, up to now all other proposed checks are compromises which have disadvantages as well. Cool. So you would special case a key of /dev/*random, and perform only those two checks? In other words, would my existing configuration swap/dev/hda2 /dev/urandom swap start working again? That sounds like a nice resolution. that's the plan. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Sun, Jun 25, 2006 at 04:13:20PM +0200, Jonas Meurer wrote: On 21/06/2006 Andrew Pimlott wrote: True, but this can't be configured in crypttab, which makes it effectively unavailable. Moreover, it wouldn't provide much additional safety. Presumably, a hypothetical luksrandom keyword in crypttab would mean: check that it's a luks partition, than re-luksFormat and luksOpen with the same random key. do you see any advantages in providing this? i don't like the idea of invoking luksFormat automatically in any case. No, just thinking out loud. Cool. So you would special case a key of /dev/*random, and perform only those two checks? In other words, would my existing configuration swap/dev/hda2 /dev/urandom swap start working again? That sounds like a nice resolution. that's the plan. Wonderful. Thank you. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 22/06/2006 Florian Weimer wrote: * Jonas Meurer: why do you see any problems? it does nothing else than checking for a known filesystem before destroying any data on the source device. The current setup doesn't work with volume managers and things like that. These don't have any partition types AFAIK. Most people will call the volume something which contains the string swap, I guess, so you could use that to check. Or just note the expected volume size in the configuration file. how do you mean? even if the source device is a logical volume, it may contain a filesystem. or do you mean the old swap check script which checked for partition type 'swap'? this one doesn't exist in current cryptsetup any more. but here, you're right as it fails for logical volumes. the latest plan for swap encrypted with a random key is to check per default for known filesystems on the source device, and fail if one is found. this protects filesystems, uncrypted swap partitions and LUKS devices from being overwritten. the only cases that are known to me, where data loss may still occur are encrypted devices without an identifying header, like plain dm-crypt devices. i don't like the idea to check for string 'swap' in the source or target device, as this would enforce even more restrictions to the admin. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
* Jonas Meurer: On 22/06/2006 Florian Weimer wrote: * Jonas Meurer: why do you see any problems? it does nothing else than checking for a known filesystem before destroying any data on the source device. The current setup doesn't work with volume managers and things like that. These don't have any partition types AFAIK. Most people will call the volume something which contains the string swap, I guess, so you could use that to check. Or just note the expected volume size in the configuration file. how do you mean? even if the source device is a logical volume, it may contain a filesystem. If the volume name contains the string swap, this is pretty unlikely. the only cases that are known to me, where data loss may still occur are encrypted devices without an identifying header, like plain dm-crypt devices. Logical volumes are in this category, too. i don't like the idea to check for string 'swap' in the source or target device, as this would enforce even more restrictions to the admin. Currently, it does not work at all. How could soemthing else be more restrictive? Anyway, what about my other suggestion, checking for the device size? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
* Jonas Meurer: why do you see any problems? it does nothing else than checking for a known filesystem before destroying any data on the source device. The current setup doesn't work with volume managers and things like that. These don't have any partition types AFAIK. Most people will call the volume something which contains the string swap, I guess, so you could use that to check. Or just note the expected volume size in the configuration file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 11:28:57PM +0200, Jonas Meurer wrote: On 20/06/2006 Andrew Pimlott wrote: On Tue, Jun 20, 2006 at 10:10:24PM +0200, Jonas Meurer wrote: But as I understand, a randomly keyed partition can't be done with Luks (or can it?). first, LUKS devices with random key are possible, you just need to store the random key after luksFormat, to reuse it for luksOpen. afterwards you can shred/wipe the key. True, but this can't be configured in crypttab, which makes it effectively unavailable. Moreover, it wouldn't provide much additional safety. Presumably, a hypothetical luksrandom keyword in crypttab would mean: check that it's a luks partition, than re-luksFormat and luksOpen with the same random key. The problem is, this would happily trash any normal (non-randomly-keyed) luks partition. So you really want an explicit marker that says I am disposable. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. yes, that's exactly what i suggested as well. in my opinion, up to now all other proposed checks are compromises which have disadvantages as well. Cool. So you would special case a key of /dev/*random, and perform only those two checks? In other words, would my existing configuration swap/dev/hda2 /dev/urandom swap start working again? That sounds like a nice resolution. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 19/06/2006 Andrew Pimlott wrote: Automatically formatting a swap partition is a destructive operation, so all reasonable checks should be made before doing it. It is currently not possible to positively identify a swap partition encrypted with a random key; nor is it possible to negatively identify a partition as not encrypted (with some unknown key). This gives me two ideas: at least we can be sure that devices with a known filesystem don't contain encrypted data. so we can skip those. 1. Create a marking for partitions to be encrypted with a random key, allowing for the positive identification above. Perhaps this should be part of LUKS. i see this more as a feature than as a bug. there may exist situations where you don't want your device to be marked as 'contains encrypted data'. 2. If I use LUKS for all encrypted filesystems, I believe it is possible to perform the negative identification above. That is, if I don't see the LUKS header, and the partition does not have an unencrypted volume, then it is safe to destroy. So let me promise that I have no non-LUKS encrypted filesystems. i'm not sure that i understand. you mean that all encrypted non-swap devices should be LUKS devices? we should never expect that. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 20/06/2006 Dick Middleton wrote: What I don't understand is why it's doing any checks at all when not requested. It seems to me that checking for the existence of a filesystem on an arbitrary partition is a bold assumption. That is properly the business of mount. why do you see any problems? it does nothing else than checking for a known filesystem before destroying any data on the source device. you will never have a valid filesystem on a device that last has been used as encrypted swap. But if having a default is generally deemed desirable then there must be a checks=none capability or nochecks option. that is true, at least for swap partitions. current implementation always checks swap partitions. i will try to summarize the changes that should be implemented in the next version: - add a checks=none option for swap - check for valid fs on src device for plain dm-crypt swap per default - check for LUKS device before any luksOpen, regardless if swap or not - don't run other checks per default, but provide as many optional as reasonable please correct me if i forgot something. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 06:40:56PM +0200, Jonas Meurer wrote: On 19/06/2006 Andrew Pimlott wrote: 1. Create a marking for partitions to be encrypted with a random key, allowing for the positive identification above. Perhaps this should be part of LUKS. i see this more as a feature than as a bug. agree there may exist situations where you don't want your device to be marked as 'contains encrypted data'. Right, however most users would be happy to put such a mark if it increased safety. So it would be a nice option. 2. If I use LUKS for all encrypted filesystems, I believe it is possible to perform the negative identification above. That is, if I don't see the LUKS header, and the partition does not have an unencrypted volume, then it is safe to destroy. So let me promise that I have no non-LUKS encrypted filesystems. i'm not sure that i understand. you mean that all encrypted non-swap devices should be LUKS devices? we should never expect that. I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 20/06/2006 Andrew Pimlott wrote: there may exist situations where you don't want your device to be marked as 'contains encrypted data'. Right, however most users would be happy to put such a mark if it increased safety. So it would be a nice option. yes, that's exactly what Michael proposed. write some identifying flag into the first or last sector of a device to mark it as plain dm-crypt swap. patches are welcome ;-) 2. If I use LUKS for all encrypted filesystems, I believe it is possible to perform the negative identification above. That is, if I don't see the LUKS header, and the partition does not have an unencrypted volume, then it is safe to destroy. So let me promise that I have no non-LUKS encrypted filesystems. i'm not sure that i understand. you mean that all encrypted non-swap devices should be LUKS devices? we should never expect that. I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. looks like overkill for me. users who use only luks don't need to specify that. 'cryptsetup isLuks' is run against every source device anyway, before invoking 'cryptsetup luksOpen'. so there should be no need for a LuksOnly option. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On Tue, Jun 20, 2006 at 10:10:24PM +0200, Jonas Meurer wrote: On 20/06/2006 Andrew Pimlott wrote: I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. looks like overkill for me. users who use only luks don't need to specify that. 'cryptsetup isLuks' is run against every source device anyway, before invoking 'cryptsetup luksOpen'. so there should be no need for a LuksOnly option. But as I understand, a randomly keyed partition can't be done with Luks (or can it?). So even for a user who uses Luks for all his permanent partitions, there will still be the swap partition (or mabye a /tmp partition) that cannot be identified. If we had LuksOnly, we could be confident that those partitions are disposible. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: encrypted swap with variable key fails
On 20/06/2006 Andrew Pimlott wrote: On Tue, Jun 20, 2006 at 10:10:24PM +0200, Jonas Meurer wrote: On 20/06/2006 Andrew Pimlott wrote: I mean _if I explicitly promise so_, we should expect that. So give me some configuration directive like LuksOnly that I can set. looks like overkill for me. users who use only luks don't need to specify that. 'cryptsetup isLuks' is run against every source device anyway, before invoking 'cryptsetup luksOpen'. so there should be no need for a LuksOnly option. But as I understand, a randomly keyed partition can't be done with Luks (or can it?). So even for a user who uses Luks for all his permanent partitions, there will still be the swap partition (or mabye a /tmp partition) that cannot be identified. If we had LuksOnly, we could be confident that those partitions are disposible. first, LUKS devices with random key are possible, you just need to store the random key after luksFormat, to reuse it for luksOpen. afterwards you can shred/wipe the key. However it may still be overkill. I would be happy enough if there were a check for randomly keyed swap partitions that verifies that the source device is 1) not a formatted, unencrypted volume and 2) not Luks. That's still a good measure of safety. yes, that's exactly what i suggested as well. in my opinion, up to now all other proposed checks are compromises which have disadvantages as well. and everybody is free to add his/her own (pre)checks to encrypted partitions. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
