extra key files included in initrd

Teddy Hogeborn teddy at recompile.se
Thu Jun 20 20:44:38 CEST 2019


Jesse Norell <jesse at kci.net> writes:

>   I was looking over the contents of an initrd today and noticed some
> mandos key files present which I didn't expect, nor were needed to
> boot.  On that system I have the default pubkey/seckey files which are
> used for unlocking the root filesystem, and a second set of keys which
> are used by a backup script (which calls mandos-client to get the key
> used for encrypting the backup), and also stored in /etc/keys/mandos/.
> It appears the entire contents of that directory are included in the
> initrd.  Perhaps I missed/forgot that point in the past, but it does
> seem there is room for a bit of improvement there if the scripts which
> assemble mandos' initrd environment were more selective.  (And the
> obvious workaround for me is to store the secondary keys in a
> different directory.)

Or a subdirectory; subdirectories are not copied either; the exact code
which does the copying can be found in "initramfs-tools-hook" in the
source code, or in /usr/share/initramfs-tools/hooks/mandos on an
installed system.

But using the /etc/keys/mandos directory for your own files (or
subdirectories) is risky, since we might, at any time, introduce new
configuration files conflicting with your file names.  It is also
entirely undocumented, so it is risky to rely on this directory.

I would suggest storing your keys elsewhere, and passing the options to
use the file names to mandos-client, as you presumably already do.  If
you for some reason don't like using /usr/local/etc, which IIRC would be
the most FHS-compliant place to put them, one other suggestion might be
to use the /etc/keys directory directly.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20190620/b4a1a5b9/attachment.sig>


More information about the Mandos-Dev mailing list