partman-crypto
Hi all,
as you might know, I've been hacking on support for block device
encryption in partman lately, dubbed partman-crypto. This work has
proceeded nicely and the most basic functionality is available now.
That is, you can use a current snapshot to install[1] Debian onto
loop-AES encrypted partitions.
I'm now at a point where I'd like to share the code and hopefully find
people who know d-i better than me to review and critique it. Input on
the debconf templates is especially welcome, since this is my first
complex use of translatable templates and my english is often .. well,
let's say "suboptimal" :)
People interested in having a first look can download a first netboot
mini.iso from <http://decl.org/~max/debian-installer/>. There is also a
tarball (crypo-installer-0.1.tar.gz) with the sources and patches I
used to build the image. NOTE: this code is still alpha quality. Please
don't use it for now unless you intend to work on partman-crypto.
The work is still in progress, and of course a lot is unfinished or
missing. There is no support for either dm-crypt or dm-crypt-luks
(although that is planned and framework has provision for it - help is
very welcome!), installing on encrypted root is not implemented,
keyfiles cannot be stored and used from removable devices, etc.
For an overview of what remains to be done, from my perspective, have a
look at partman-crypto/TODO. Of course, help with any of these points -
or other things you find important - is more than welcome. I'm keeping
the partman-crypto and related sources in an SVN repository for now
which you can access at <http://svn.decl.org/public/partman-crypto/>
I also have a few questions:
1. How do I go about submitting the code for review? Do you prefer
patches sent to the list, should I commit to a peoples branch, or is
there some other preferred mechanism?
2. Some packages still require changes to build crypto d-i, which I'm
including in the patches/ directory of the source tarball. If you want
to (re-)build crypto d-i, these patches have to be applied and packages
rebuilt and put into localudebs/
gnupg build a gnupg-udeb
busybox-udeb build with uuencode
loop-aes-utils build loop-aes-utils-udeb (pending)
loop-aes-modules-i386 build loop-aes-$KVERS-udeb packages (pending)
partman include /dev/loop/$n in humandev (#320443)
I'll submit wishlist patches for these packages and implement required
changes for mine (loop-aes-*) during the next week. I wonder, are there
any side-effects for d-i from building new udebs? Does it make sense to
discuss details with you before uploading?
3. Hats-off to you guys for making such a nicely hackable installer! It
took very little time to get started writing code, building udebs and
custom images. The changes required in other d-i packages for getting
partman-crypto to work were absolutely minimal. Great work :)
4. Provides: seems to not be considered by udpkg/retriever, or perhaps
I'm doing something wrong: I need to install an alternative loop module
package that includes encryption, and which Provides: loop-modules, but
the original package is pulled in anyway. Any idea why this happens?
5. Loop-encrypted partitions use a hack in finish.d to change the fstab
entries for /dev/loop/$n to the respective "real" device and to add the
crypto-specific mount options (using sed). I decided to do take that
approach because this way filesystem specific checks and mount options
can be setup by their respective fstab.d scripts. Do you see a better
approach or any specific problems doing it this way?
6. I've written a small cdebconf plugin (newt_entropy) to help speed up
the process of creating loop-AES keyfiles. The kernel entropy pool has
very little content at the point where partman runs and would take a
very long time to get required amount of random keydata (2925 bytes). To
help speed this up, the plugin asks the user to enter random characters
on the keyboard.
Integration of this plugin with cdebconf is still rough. What I'm
doing at the moment is build the udeb from inside a configured cdebconf
tree (in src/modules/frontends/newt_entropy), since the module uses
makefiles and headers from there. The module has a separate debian/
directory. Eventually this would be good to integrate with cdebconf.
Any thoughts on how this should be done? Should plugins be built from
the cdebconf tree, and should they be included in the cdebconf udeb or
in separate packages?
The plugin plugin also exists only for the newt frontend so far, but
there is some very basic backup code using plain cdebconf in case the
plugin is not available. How about other frontends at this point? I'm
thinking about GTK for example - which I know very little about. If it
were to be implemented in GTK, the user experience could probably be
improved quite a bit by using mouse movements as input instead of (or
in addition to?) random keyboard input.
9. The loop-AES support requires a special loop.o/ko loaded in first
stage and a kernel module package (loop-aes-$KVERS) installed before
booting into second stage. Since those modules are not available in the
archive, I started working on a basic auto-building package
(loop-aes-modules-i386), which is more or less ready for upload.
<http://svn.decl.org/public/loop-aes-modules-i386>.
Of course, this package only provides modules for i386. Does anyone here
have experience with or thoughts about autobuilding external kernels
modules for more than one arch? I suppose the package could be made
Arch: any, or there could be separate packages for each architecture. If
there are experiences with this, I would love to hear about them.
10. Once loop-aes-$KVERS module packages arrive in the archive, how
could the aptinstall script determine the target kernel to decide which
module package to install? I suppose it cannot since the kernel is
chosen long after partman has run. Is there some mechanism I could use
to apt-install the right module package at a later stage?
Expect more questions from me in the near future :)
I'm looking forward to hearing your suggestions, criticisms, ideas and
of course experiences from using the current snapshot. I'll be away for
most of the weekend and so will probably be a bit slow to reply until
some time early next week.
cheers,
Max
--
[1] sid is currently not possible to debootstrap and installation fails
at the base-install stage. Things leading up to it seem to be working.
Also, the loop-AES module packages are not in the archive and so can't
be installed before booting into the second stage.
Reply to: