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

Wed Jul 21 09:01:43 UTC 2010

tags 589641 + nointeresttofix
tags 589686 + nointeresttofix
stop


On Wed, 2010-07-21 at 01:13 +0200, Jonas Meurer wrote:
> the situation with keyscripts is not perfect at all.
Just sticking with them as it is and never allow improvement won't
change this however...

> to be honest it's
> an ugly hack in my eyes.
Well... there are worse hacks I guess... they'd just need some
formalisation and most likely some mightier framework around.

> keyscripts are intended to be easy to use:
Guess that's a misconception,.. or at least I would not see and
reasonable point why it should have to be like that...

> everybody can write their own, the only prerequisite is that the
> keyscript outputs a key in the end.
... it would be actually rather problematic, as "normal" crypto-end-user
typically never see all possible implications,... I mean even we
don't,.. see the copy-key-to-initramfs-thingy you did, ... and I've also
spotted some possible security problem in my own scripts...


> keyscripts which depend on external
> binaries
Aren't that basically all? With just what you have without any external
deps,... what can you do but,... read-passphrase..


> for sure cannot be used for decrypting devices which do
> contain these binaries.
That's the bug here


> but that's a problem, admins need to solve on
> their own.
uhm... interesting... o.O

> either they encrypt the whole root filesystem,
Well that won't help,... /usr is not part of the root-fs.


> or they
> take precautions on their own, that the dependencies in question are
> available at the time cryptdisks invokes the keyscript.
Than we should mark the current scripts we ship as marked broken for
setups that have not just one fs with the OS on it, so that people won't
accidentally end up in an unbootable system...


>  copying external
> binaries to a second place in root filesystem for sure is not an option
> at all.
Well the more I think about that one,.. the more I'd choose it...
It's nothing different from what is already done with initramfs
images...

>  that would be a big security problem,
also... not more thant with initramfs images,... the only security issue
I can see (ATM) is that you might miss security updates for some time.

>  and it's not FHS compliant
> either.
Wouldn't see how FHS forbids this,... then it would also forbid
initramfs images.


> decrypting all dm-crypt devices in initramfs is not an option either,
Yeah... I also dislike that idea more and more... it would simply break
the intention of initramfs images.


> 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.
Well why? At least why with things that are not to difficult to solve
like that issue...


> I don't
> think that adding more complex keyscripts to the debian archive is a
> good idea at all.
Even after trying,... I could found no arguments why we should keep us
artificially "small"...
We could drop 80% of the distro for that reason,... with respect to
cryptsetup, all support for splashy/usplash/etc... which is just
cosmetic bullocs.


> admins who use complex setups need to take care of
> them on their own.
To be honest.... than we really can remove cryptsetup (and many other
packages) alltogether,.. as everything they do is "special"...


>  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.
Actually,... using such intermediate layers is the only way to prevent
simply attacks that would make the whole dm-crypt thingy pretty much a
toy... which is quite easily provable with simple examples...


> 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.
All such cases,... would be bugs by the policy,... but well.. I recently
had to learn that many maintainers do not care on that silly annoying
document...


> 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.
Well... see the arguments above,... but I closed them anyways... guess
that counting the leaves of the tree before may lab is a better way to
invest the precious time left in my life...


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3387 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100721/4cf75f55/attachment-0001.bin>