Am Mittwoch, den 02.02.2005, 13:19 -0800 schrieb Matt Mackall: > From looking at the dm_crypt code, it appears that it can be > interrogated to report the current key. Some quick testing shows: > > # dmsetup table /dev/mapper/volume1 > 0 2000000 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0 > > Obviously, root can in principle recover this password from the > running kernel but it seems silly to make it so easy.
I already tried that. It took me about five minutes using a shell, dd and hexdump to get the key out of the running kernel... > Moreover, it seems this facility exists to support some form of > automated table storage (LVM?). As we don't want anyone/anything > accidentally storing our passwords on disk in the clear, we probably > shouldn't facilitate this. Perhaps we can stick something here like > "<secret>" that the dm_crypt constructor can reject. Yes, the reason is that the device-mapper supports on-the-fly modifications of the device. cryptsetup has a command to resize the mapping for example. It can do that without asking for the password again. Features like this are the reason I'm doing this. Userspace tools should be able to assume that they can use the result of a table status command to create a new table with this information. An alternativ would be to use some form of handle to point to the key after it has been given to the kernel. But that would require some more infrastructure. I could imagine something like this: Some kernel infrastructure for key management. It can hold keys which are referenced by some form of handle. The keys are refcounted and wiped if the reference count drops to zero. If you want to create a dm-crypt mapping (or something else that uses some form of cryptographic key) you create a new handle and assign the key. Then you give the handle to dm-crypt which increments reference count. When cryptsetup exits its reference to the key is dropped but the key still has a reference from the active dm-crypt mapping. Later on another application could then safely do something with that handle. As long as an application or in-kernel user references the key it won't be dropped so it's safe for a userspace application to play around with it. BTW: The setkey command also seems to return the keys in use for IPSEC connections.
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil