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

[Jonas Meurer]

Christoph, please at least try to understand the maintainers point of
view: you're correct, when supporting a setup within a package is easy
to do, that should be done. and yes, that's the reasons why packages do
exist in the first place. but that's one of the main tasks of a
maintainer: chosing between complex packages, supporting many corner
cases, and keeping the package simple by not supporting special setups
out of the box.

in this particular case, the price to pay is to high in my eyes: neither
splitting keyscripts into a seperate package, nor copying binaries from
/usr to some place in root fs is an option in my eyes. that's the sole
reason why i chose the option: let the admins take care on their own.

On 21/07/2010 Christoph Anton Mitterer wrote:
> 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...

right, but blowing up the current implementation is not the way to go.

> > 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...

Christoph, if you don't trust the local admins, then you need to
distribute fs images which they pretty please mount read only, in order
to circumvent any mistakes they do. you're right when trying to make the
admins life/tasks as easy and as secure as possible, but not for any
price.

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

yes. like it or not, the package cannot support any corner cases. if
people need to setup complex systems, they need to know what they do.
there's other solution. we try to make their lifes easier, for example
by providing the cryptdisks/crypttab facilities around cryptsetup, which
do support custom keyscripts out of the box. that already a great step.

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

people who encrypt the root filesystem usually do have /usr on the root
fs. ubuntu even stopped to support sepearte /usr fs, if I remember
correctly.

> >  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.

no, the initramfs is a crafted image, it's not a directory containing
copies of binaries. your suggestion would break intrusion detection
systems, rootkit checkers and make it even harder for sysadmins to keep
their system clean.

> > 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...

please see above ...

> > 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.

see above ...

> >  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...

please elaborate. why is a gpg-encrypted keyfile more secure than a LUKS
passphrase?

> > 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...

no, they're not. please show me the section in policy which requires a
package to depend on all software which is needed for parituclar
functions to work ...

> > 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...

i do understand that you're frustrated, but please try to understand the
point of view at the other end of the internet.

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/86c7d865/attachment.pgp>