10:23 a.m.
Hi Coiby,
So sorry to say that I forgot to back up some old emails so I lost them...
Plan 3 is not a good idea either. Making things too complicated and not safe.
Plan 4 is definitely the right choice, and no one was against it, and
I vaguely remember it is doable as we were discussing. As the
cryptsetup tool stores the device key as a logon key in kernel (logon
so userspace can't access the key content), the idea to keep the logon
key used by dm-crypt consistent in kernel over kexec reboot, just keep
the reference in userspace (eg. pass a key-reference in kernel
cmdline). cryptsetup tool in kdump kernel can just use that key
reference to setup the dm-crypt device again. The only problem was
that key have KEY_SPEC_THREAD_KEYRING flag, which means it's reference
was no longer available in user space too after the initial cryptsetup
thread exited. May need to loose this security measure a little bit,
eg. to KEY_SPEC_GROUP_KEYRING? You can definitely reboot the
discussion in the cryptsetup mail list.
Coiby Xu <coxu(a)redhat.com> 于2021年11月4日周四 下午6:05写道：
>
> Hi Kairui,
>
> On Tue, Apr 20, 2021 at 05:23:49PM +0800, Kairui Song wrote:
> >Hi,
> >
> >Thanks a lot, these info are very helpful.
> >Better to keep it for debugging for now, and ask users to use it very carefully.
> >
> >On Tue, Apr 20, 2021 at 3:54 PM Milan Broz <gmazyland(a)gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> TL;DR what you are trying to do is to actually reverse many security
measures
> >> we added. It is perhaps acceptable for debugging but hardly for real generic
system.
> >>
> >> - using memory-hard function increases cost of dictionary and brute-force
> >> attacks
> >> You can always decrease amount of memory needed, but you should do it only
> >> if you know that security margin is ok (like password is randomly generated
> >> with enough entropy).
> >>
> >> - key is in keyring to remove possibility for normal userspace to receive
> >> the key from kernel. Moreover, there is no need to retain kernel in keyring
once
> >> dm-crypt device is activated. (It is still in kernel memory but only in
crypto
> >> functions context). (Systemd also uses keyring to cache passphrase but
that's
> >> different thing.)
> >>
> >> You can still use old way for activation with --disable-keyring activation,
> >> but then you disable this possibility.
> >>
> >> More comments below.
> >
> >How about plan 3 and 4?
>
>
> Have you got any reply from Milan about his input on plan 3 and 4? If
> so, can you forward his email(s) to me? Thanks!
>
> >
> >> 3. Let kdump use some custom helper/service to load all needed
> >> resources in the early initrd boot stage, prior to
> >> systemd-cryptsetup(a)%s.service. It will ask the password / parse the
> >> keyfile and load kdump, then provide info for systemd-cryptsetup or
> >> just do the setup. Or maybe let systemd-cryptsetup support some kind
> >> of "plugins" so other tools can use it.
> >
> >Some details could be changed/improved, but
> >systemd-cryptsetup(a)%s.service will prompt for a password or use a
> >keyfile anyway.
> >So I think at this point, loading kdump with the volume key should be
> >safe? At least long as the kdump kernel/environment itself isn't
> >compromised. Loaded kdump resources can be restricted to be only
> >accessible from the kernel side.
> >After panic, kernel kexec jumps to kdump kernel, and that's an
> >minimized emergency environment that only lives for a very short
> >period.
> >
> >> 4. A better and safer solution seems to keep a consistent key ring
> >> between kexec boots but also more complex and difficult as different
> >> arch implements kexec differently.
> >
> >Maybe plan 4 will be a good idea if doable? Since that keeps the key
> >consistent in the kernel between kexec boots, and cryptsetup can just
> >reuse it.
> >
> >--
> >Best Regards,
> >Kairui Song
>
> --
> Best regards,
> Coiby
>