On Tue, Jul 18, 2006 at 04:38:25PM +0200, Max Vozeler wrote:
> On Sun, Jul 16, 2006 at 08:50:09PM +0200, Lionel Elie Mamane wrote:
> I have been looking through the patch, and found a few
> questions/comments. I'd be interested what you think.
> There should probably be a NEWS.Debian entry to let users know
> about the new functionatily
Yes :)
> but also to warn them that it might interfere with their existing
> encrypted root setup.
Well, if they have a working setup, they probably made it by dropping
files in /etc/initramfs-tools/{scripts/*,hooks}/ . Yeah, we need to
warn them.
> Although, I think most if not all setups should be unaffected as
> they are likely using "/dev/loop$n / ..." style entries in
> /etc/fstab.
Hmm... Maybe.
>> +++ loop-aes-utils-2.12r/debian/initramfs-tools-hook
> ...
>> + gpgkey=*)
>> + rootgpgkey=${opt#gpgkey=}
>> + ;;
>> + gpghome=*)
>> + rootgpghome=${opt#gpgkey=}
> Should this be s/gpgkey/gpghome/ ?
Yes, and the time after that, too:
gpgkey=*)
rootgpgkey=${opt#gpgkey=}
;;
gpghome=*)
rootgpghome=${opt#gpghome=}
(...)
# Prepare the initramfs
if [ -n "${rootgpgkey}" ]; then
mkdir ${DESTDIR}/keys/
cp "${rootgpgkey}" ${DESTDIR}/keys/rootkeyfile.gpg
copy_exec /usr/bin/gpg /bin/
loopaes_opts="${loopaes_opts},gpgkey=/keys/rootkeyfile.gpg"
fi
if [ -n "${rootgpghome}" ]; then
cp -R "${rootgpghome}" ${DESTDIR}/.gnupg
> I wonder, could there be unwanted side-effects from copying the
> rootgpghome directory into the initramfs, like exposing secret keys
> on the unencrypted /boot partition?
Hmm... They are supposed to be password-protected, but indeed this is
one layer of protection gone.
> OTOH I suppose users who specify gpghome= probably know what they
> are doing, so maybe this point is moot.
Fundamentally, if that option is there, it means that at least some
files in there are needed to mount the encrypted root. No good way to
know which ones, as far as I see. So difficult to be more selective
than taking the whole directory. But fundamentally, these files _need_
to be in an unencrypted partition.
We can put a note in README.Debian instructing people to prepare a
minimal GnuPG home with nothing more than what is needed.
> More importantly: The initramfs file in /boot is by default
> world-readable. If we copy root.gpg into it, it will be readable by
> all users. Same for files in $rootgpghome. Maybe you have an idea
> what we could do here? The initramfs-tools maintainer told me that
> there is no existing way to say: Generate this initrd.img-$foo mode
> 0600. We would also have to take care of temp file permissions.
I don't see any reason he wouldn't take a patch for both these
things. Having temp files 0600 wouldn't hurt, so we could have he
patch do it always. As for the initrd.img-$foo file, ... any reason
not to also always do it? We can easily make it an option, I suppose.
> How about storing the keyfile directly in /boot/keys/, would that be
> an valid alternative? Just a quick idea, I haven't thought this
> through :-)
It would make the boot-time script more complex, it would have to
mount /boot/ to find the key. Possible, but if we can keep it simple
and thus more robust, the better.
> ...
>> +manual_add_modules loop
> Maybe we could check which encryption= is specified, and load
> loop_{serpent,twofish,blowfish} here if required ?
Yes, and load it in the boot-time script.
>> +++ loop-aes-utils-2.12r/debian/initramfs-tools-script
> ...
>> + local opt
>> + local IFS=", "
>> + for opt in $loopaes_opts; do
>> + case $opt in
> ...
>> + gpghome=*)
>> + rootgpghome=${opt#gpgkey=}
> s/gpgkey/gpghome/ ?
Yes.
>> +# Use /sbin/losetup to make sure that we get the loopaes modified one,
>> +# not the busybox one.
>> +/sbin/losetup ${losetup_opts} "${rootloop}" "$ROOT"
> I think asking only once for the passphrase can be frustrating for
> users if they make a typo. :-)
They can reboot :) More seriously, doesn't losetup give the user
several tries? If not, why not do fix this _there_?
> About documentation. Do you think you could add a small README about
> how the scripts can be used and how one would manually create a
> suitable setup?
At some point in the future, yes. I'm going to install a new machine
in the next weeks, I'll take the opportunity to document all the steps
I take.
> And a last question: I would like to add a check that there is
> indeed a loop-AES module installed at the time of initramfs
> creation/update. Otherwise the user could end up with an initramfs
> unable to boot their system, no?
Fundamentally, they have a kernel unable to boot their system. Warning
them would be nice, yes. I'm not 100% clear on how we can tell the
"normal" loop.ko from the loop-aes one. I suppose you would know?
Do you use a VCS of some sort to manage the package? If we both start
making modifications to the same feature, it would be easier to
synchronise using it rather than throwing patches around.
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
