Hi Lionel,
I've been busy the last days, sorry for the slow reply.
On Tue, Jul 18, 2006 at 09:42:49PM +0200, Lionel Elie Mamane wrote:
> On Tue, Jul 18, 2006 at 04:38:25PM +0200, Max Vozeler wrote:
> > [ NEWS.Debian ]
>
> 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.
Yes. If you don't beat me to it, I will write a small text
before upload. :-)
> > 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.
I was thinking of the root-on-loop-AES method described in
loop-AES README (build-initrd.sh). It has a separate losetup step
before mount, and fstab lists the loop device as backing device.
But on second thought, those setups are not likely to be using
Debian kernels with initramfs-tools.
> 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.
Agreed on both points; I think that's reasonable.
> > 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.
I can't think of reasons against it. We should talk with
Maximillian Attems what he thinks can be done.
I've had a quick look at the available hooks today. At the start
of mkinitramfs umask is initialized to 0022. Then it sources
scripts in /usr/share/initramfs-tools/conf.d/, where we could set
umask 077. I've verified that this enforces correct permissions
of the temporary files, but not of the image itself. The image is
created with touch during getopt parsing -- too early. But then
that is just a thought exercise. I'm not sure we'd want to rely
on setting umask through a sourced script where any other script
could change it back. And it'd be nicer of course if there was
support directly in initramfs-tools.
> > 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.
Ah, true; I didn't consider that we'd need to mount /boot. This
indeed makes it quite more complex.
> > ...
> >> +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.
I saw you've implemented this in version 2; Thanks!
> > 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_?
At the moment losetup doesn't support retries. In the long run
it would indeed be useful to add a retry option to losetup; I
think I will suggest this to upstream or add it myself some time.
For the moment though, working around it in sh is much easier ;-)
Plus, tested code for it is already available in checkfs-loop.
> > 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.
That'd be great, thanks.
> > 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?
In the (old) initrd-tools scripts I used nm loop.ko and checked
for a loop-AES specific symbol. But we'd not want loop-aes-utils
to depend on binutils I suppose :-)
As simple heuristic, it could do "grep -q loop_compute_md5_iv
loop.ko". That should also work if the module was stripped, but
I'm not sure how reliable it is.
> 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.
Yes, I use SVN. Unfortunately, the "master" repo is on my laptop
and so there is only a read-only mirror available online.
(http://svn.hinterhof.net/public/loop-aes-utils/{trunk,tags})
I'd be open to using another approach though, like using bzr and
me merging into SVN or something. :-)
On Tue, Jul 25, 2006 at 07:22:41PM +0200, Lionel Elie Mamane wrote:
> Here is a second version:
>
> - Support for loop-aes in the intramfs can be forced off or on.
>
> - Still no documentation.
>
> Attached is a cumulative patch (against plain loop-aes-utils) and an
> incremental patch (against version 1 of the integration).
Thanks for the update. I'll commit it to SVN in a minute.
...
> + # Sanity check
> + if [ -z "${loopaes_opts}" ]; then
> + # Apparently the root partition isn't encrypted
> + echo "No root-on-loop configured, skipping"
> + exit 0
> + fi
> +
> + local opt cipher
> + local IFS=", "
Small pet-peeve: Indentation here is not consistent. ;-)
cheers,
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
