[pkg-cryptsetup-devel] Bug#589686: Bug#589686: cryptsetup: split out keyscript in separate packages

[Jonas Meurer]

Hey Christoph,

the following is intended as answer to both bugs, #589686 and #589641:

i guess you already forefeel my reaction: i don't like that idea at all.

the situation with keyscripts is not perfect at all. to be honest it's
an ugly hack in my eyes. but i don't know a better solution for this
complicated situation yet. keyscripts are intended to be easy to use:
everybody can write their own, the only prerequisite is that the
keyscript outputs a key in the end. keyscripts which depend on external
binaries for sure cannot be used for decrypting devices which do
contain these binaries. but that's a problem, admins need to solve on
their own. either they encrypt the whole root filesystem, and thus
dependencies of the keyscript are included into the initramfs, or they
take precautions on their own, that the dependencies in question are
available at the time cryptdisks invokes the keyscript. copying external
binaries to a second place in root filesystem for sure is not an option
at all. that would be a big security problem, and it's not FHS compliant
either.

decrypting all dm-crypt devices in initramfs is not an option either,
for several reasons. and you already know them: loads of prerequisites
might be required in order to make the source device available (i.e. if
it's accessed over network, if it's managed by block device tools, ...).
I guess I don't need to continue with reasons, you get the picture.

I guess the main point is: cryptsetup is not going to support every
theoretically possible setup. this is not even possible. thus you need
to accept, that uncommon setups require extra work by the admin. you
cannot automate everything, even with a flexible package management
system.

On 20/07/2010 Christoph Anton Mitterer wrote:
> Not sure whether I've already suggested this and it was just reject... so simply
> close it if so.
> 
> We should perhaps consider, to split out the keyscripts in separate packages.
> 
> I mean e.g. something like:
> cryptsetup-openct
> cryptsetup-opensc
> cryptsetup-openssl
> etc.
> (not yet sure about passdev...)

this is not a good idea either. rethinking the whole situation, I don't
think that adding more complex keyscripts to the debian archive is a
good idea at all. admins who use complex setups need to take care of
them on their own. and encrypting the keyfile with another crypto tool
(openssl, gnupg) is not really appreciated anyway. adding an extra layer
of encryption to the device encryption is not going to add extra
security in most cases. to be honest i only see a reason for keyscripts
like passdev, decrypt_derived, decrypt_openct and decrypt_opensc, not
for decrypt_gnupg and decrypt_ssl, at least not the way they currently
work.

and, like it or not, that's the way debian packaging works. lots of
packages contain software with extra features/plugins/... which do only
work if extra software is installed. but they never depend on all
the packages in questions. if the usecase is a common one, they suggest
or even recommend packages, but for features only used rarely, the admin
needs to take care of dependencies.

and no, i'm not going to split all keyscripts into seperate packages.
debian already has way to much packages. packaging small shell scripts
as seperate packages is considered as very ugly style, and heavily
discouraged/depreciated by the debian developers community.

On 19/07/2010 Christoph Anton Mitterer wrote:
> I have not tried this out, nevertheless I'm quite sure it happens as I describe:
> 
> - In Debian, it's totally ok, to have /usr on non-root-filesystems (even remote filesystems are ok,
>   but I guess that's rather stupid when it comes to disk encryption.
> 
> - It's also completely ok (and very reasonable in order to secure against offline attacks)
>   to encrypt /usr.
> 
> - Many keyscripts depend on content within /usr, e.g. my personal OpenPGP key scripts, or openct,
>   opensc and openssl)
> 
> 
> It's quite obvious that this will fail:
> The root-fs itself can be well decrypted (everything needed is in the initramfs), but then
> we pivot root, and all that stuff is gone... as soon as we try to decrypt any other device which
> uses a keyscript with dependecies in /usr,.. (e.g. /usr-fs itself)... we'll fail.
> 
> 
> I guess there is no solution but one:
> Decrypt all such devices in the initramfs image.
> 
> But this has of course many problems:
> a) In case we support multilayered block devices,... (as described here:
>    http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices )
>    we're fucked ^^... well at least everything gets extremely complicated
> b) If we'd already mount more than just root-fs during initramfs... will the
>    normal init-system boot break?

see above.

i hope you see my points. i'd like to close the bugreports again. if you
still consider either of your suggestions as a good idea, please
elaborate.

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100721/c6f88264/attachment-0001.pgp>