Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: About Bug#371135: suggestion

[Jonas Meurer]

On 16/06/2006 Mika Bostrom wrote:
> >yes, but initially the idea was to only check where we can be absolutely
> >sure that the check has no corner cases.
> 
>   I claim that this is impossible. There is no way to be absolutely sure
> about non-destructiveness of the operation. I'll try to explain.
> 
> [...]
>
> >in this case we will never find a known fstype on the cryptsetup target
> >device, as the random key will always differ.
> [...]
> >- check per default only if we might destroy data
> >- check per default only if the check is secure, has no corner cases
> >- support any other kind of check, but don't activate it per default
> 
>   With changing keys there is absolutely no way to identify what is
> valid swap space area. I see two possible approaches that _might_ be
> _theoretically_ doable:
> 
>   1. If crypttab defines an encrypted swap, use vol_id check for both
>      the created mapping AND the actual device.
> 
>   2. Use Jari Ruusu's watermark attack and explicitly disallow ESSIV
>      encryption mode for swap.
> 
> 
>   Trouble with case 1 is that it still does not catch a human error: The
> user could have fe. encrypted /home along with swap, and mixed the
> devices for these two lines. The additional test only catches the case
> that encrypted swap is erroneously defined on top of an unencrypted
> filesystem. 

exactly. in my opinion the following would be the best checksystem:

encrypted swap with a static key:
	- check source device with vol_id, skip if any FS is found.
	- if not, check destination device for a swap FS, skip if not
	  found.

encrypted swap with a random key:
	- check source device with vol_id, skip if any FS is found.
	- explicitly warn in README.Debian that data loss is likely
	  if a device with [i.e. encrypted] content is used.

in general, all plain dm-crypt source devices should be checked for
'unknown volume type' before cryptsetup is started. if any known FS is
found, the partition is not encrypted with plain dm-crypt.

for LUKS partitions, we already check with 'cryptsetup isLuks'.

so except for LUKS, the precheck needs to be improved for all cases.
postcheck only needs to be updated for swap with static key.

...
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20060616/3a13bf0a/attachment.pgp