Coiby Xu <coxu(a)redhat.com> 于2021年11月5日周五 下午6:10写道:
Hi Kairui,
On Thu, Nov 04, 2021 at 11:23:14PM +0800, Kairui Song wrote:
>Hi Coiby,
>
>So sorry to say that I forgot to back up some old emails so I lost them...
That's fine.
>
>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?
According to [1], "using this feature dm-crypt no longer maintains a
direct key copy (but there's always at least one copy in kernel
crypto layer).". So maybe KEY_SPEC_THREAD_KEYRING isn't a problem since
the master key is always there.
Yes, it is still there, but the reference is dropped, so userspace no
longer have the reference, and can't re-setup the dm-crypt. Kernel
can't setup dm-crypt device by itself.
Another question seems to be more concerning is how we can retrieve the
master key in the 2nd kernel? It seems currently there is no way to pass
data from the 1st second to 2nd second kernel. I'm aware there is work
using the so called "kexec buffer" to carrying the IMA measurement list
across kexec. But the patches haven't been merged.
You can check "security/integrity/ima/ima_kexec.c" in kernel and also
check git log of that file, this should be the IMA measure list
carrying feature you are talking about? It's merged, the patch may get
some other update before being merged, so it looks a bit different
from that mail.
>
> [1]
https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/Keyring.txt
>
> [2]
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-November/150790.html
>
> >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
> >>
> >
>
> --
> Best regards,
> Coiby
>