[Pkg-cryptsetup-devel] Re: Bug#376588: ITP: cryptmount -- a utility for accessing encrypted filesystems

R.Penney rwpenney at users.sourceforge.net
Wed Jul 5 20:29:29 UTC 2006


Jonas,
	Thanks for your interest in cryptmount (please note the lack of 'o',
and the earlier ITP Bug#375008).

	As the package author, perhaps I can respond to a few of your comments.

	Firstly, there is certainly significant overlap between what
cryptmount is able to do and what one can do with cryptsetup, but there
are some important differences that I felt would be very difficult to
address by building directly on top of cryptsetup. In particular,
it seemed rather awkward to support filesystems within loopback files,
nor could I see an easy way of allowing ordinary users to mount
filesystems using cryptsetup without giving them far too much power
through making cryptsetup setuid or wrapping it in sudo. Therefore
cryptmount set out as being a far safer tool for user-mode mounting of
dm-crypt filesystems, while supporting automatic setup of loopback
devices where needed.

	I am aware of the mechanisms behind the /etc/crypttab within
Debian, and have certainly found these to be extremely useful. However,
these still didn't address the problem of user-mode mounting. I've also
been sceptical for a while about storing all the many parameters needed
for typical encrypted filesystems within a line-based configuration
file. So with cryptmount, I've tried to create a text-based config-file
that is far easier to comment and far freer in its layout than is
possible with recent versions of the debian cryptsetup package.
However, at present the /etc/cryptmount/cmtab file doesn't give direct
support for encrypted swap partitions, even though one should be able to
set these up via 'cryptsetup --prepare <target>' as part of a future
/etc/init.d script.

	On the topic of LUKS support, I am aware that this would be a
very attractive piece of functionality to add into the mix. At present I
am reorganizing the crypto-library interfaces within cryptmount to make
it easier to support keyfiles managed by either OpenSSL or libgcrypt,
and this infrastructure is likely to make it easier to support LUKS
keys in future. However, that is probably quite a few months away.

	Clearly there are lots of people working on different styles of
solution to the encrypted-disk problem, and no-one seems to have found
the perfect mix of features yet. Naturally, I'd be very keen
to contribute to discussions about how to further improve encrypted-disk
support within debian.

		Kind regards,
			RW Penney


+--   on Wed, Jul 05, 2006 at 07:23:57PM +0200, Jonas Meurer wrote:   ---+
> On 03/07/2006 Baruch Even wrote:
> > * Package name    : cryptomount
> >   Version         : 1.0.1
> >   Upstream Author : rwpenney«AT»users«DOT»sourceforge«DOT»net
> > * URL             : http://cryptmount.sourceforge.net/
> > * License         : GPLv2 or later
> >   Programming Lang: C
> >   Description     : a utility for accessing encrypted filesystems
> > 
> > cryptomount enables the user to simply create and mount an encrypted
> > device based on dm-crypt. It can handle either a raw device or a loop
> > mounted file as the base for dm-crypt.
> > 
> > It offers the following advantage:
> > 
> >     * access to improved functionality in the kernel
> >     * transparent support for filesystems stored on either raw disk
> >       partitions or loopback files
> >     * separate encryption of filesystem access keys, allowing access
> >       passwords to be changed without re-encrypting the entire
> >       filesystem
> >     * storing multiple encrypted filesystems within a single disk
> >       partition, using a designated subset of blocks for each
> >     * rarely used filesystems do not need to be mounted at system
> >       startup
> >     * un-mounting of each filesystem is locked so that this can only be
> >       performed by the user that mounted it, or the superuser
> >     * encrypted filesystems compatible with cryptsetup
> >     * encrypted access-keys are compatible with openssl
> 
> hello Baruch,
> 
> i like the idea of cryptomount, as it seems to have advantages over
> cryptsetup. for example cryptsetup does not support to store multiple
> filesystems on one disk out of the box.
> 
> nevertheless most of cryptmount seems like a reinvention of cryptsetup,
> or cryptdisks.
> 
> do you know the cryptsetup package from debian? we have a rather complex
> initscript called cryptdisks there, which implements lots of additional
> features for encrypted disks.
> additional, cryptsetup has support for LUKS devices, which cryptomount
> doesn't have.
> 
> maybe you're interested in joining the maintainer group:
> Debian Cryptsetup Team <pkg-cryptsetup-devel at lists.alioth.debian.org>
> 
> we could maintain cryptomount as an additional package or discuss the
> possibility to merge the advantages into cryptsetup/cryptdisks.
> 
> David Härdeman currently tries to reimplement cryptdisks (the
> initscript) as a standalone wrapper for cryptsetup, written in c.
> the idea is to implement a system similar to mount, with a /etc/crypttab
> and similar syntax.
> 
> maybe we can join our efforts to develop a good implementation for
> encrypted harddisks in debian :-)
> 
> greetings
>  jonas
> 
> ---
> [This E-mail scanned for viruses by Declude Virus for the IOP]
> 
> 



More information about the Pkg-cryptsetup-devel mailing list