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
signature.asc
Description: Digital signature
